As Anytype uses IPFS, which, as far as I’m aware, means the encrypted data is essentially public, which puts an even stronger emphasis on post-quantum cryptography. Even though the encryption is safe today, if it’s easy for someone to get a large number of users’ encrypted data, they could potentially decrypt it in the future and compromise essentially all Anytype users, which is especially important when Anytype markets itself as “for life”.
I’m not very familiar with which algorithms are/aren’t quantum-resistant, and couldn’t find much information on how safe the exact encryption Anytype uses is (“AES with stream encryption with CFB mode”, source). Anytype also doesn’t seem to mention this on their docs/main page.
Does Anytype use post-quantum cryptography? Was this something that was considered, analysed and prioritised? Anytype’s docs mentions it uses a private network. Do nodes use authorisation to prevent someone from downloading all Anytype data, making this attack much less viable?
This isn’t something I’ve thought much about with other services, but it was something I thought of when I heard Anytype uses IPFS due to it potentially being possible to get large amounts of encrypted data without needing to MitM, making it easier for this to be done in the future.
I don’t think it matters. Even if state-of-the-art encryption is used, which is generally the case, there’s no telling it will remain uncracked tomorrow. It is possible the encryption algorithms we use today are all deprecated before quantum computing is employed against encryption. This is one of the reasons why some users want to have the option to keep their data completely offline, only synced between the devices that they own, in Anytype.
I agree with @BGray. I am not an expert on this, but I suppose that this should be considered mostly by cryptographers. It’s just an application of encryption in Anytype. What Anytype can do is to utilize the encryption that is strong enough for now.
But of course, @Orangutan’s concern should be considered seriously, because privacy and security are high priority issues for Anytype in the future.
I agree and that’s something I didn’t consider. Encryption (and security in general) is a moving target and is something that has to be “monitored”, which is something I forgot about at first. I’m sure if the current encryption Anytype uses had a major vulnerability published it would be updated, but I am still interested in Anytype’s quantum safety, as that is a potential “vulnerability” that we do know about and can be worked on in advance. I’m also interested in how easy/hard it would be for a user to obtain a user’s encrypted data (mainly through IPFS) as I think that was the main thing that gave me concerns due to it potentially being easier to get the encrypted data in the first place. For example, what would be the possible ways for a random person to obtain my encrypted data, excluding accessing the unencrypted data on my device/the key stored on my device?
A good rule of thumb. Never put out to the public sphere anything that would cause you significant harm were it to become public in a real sense. Every code can be cracked with sufficient time and resources, with the occasional human error lending a hand. Think of how the enigma code was cracked.
The encryption anytype uses today is relevant to the “for life” application.
Any data encrypted in a non-quantum resistant way, is going to be decryptable when quantum becomes mainstream. Why would we not protect against that?
Security is a moving target, so staying ahead of the attacks seems the reasonable thing to do. What’s the point of security if we’re not?
Data tends to linger, get replicated, any updates to data encryption while the previous encrypted copies are to be found anywhere leaves those copies to be available for decryption later.
As long as an Encabulator - https://www.youtube.com/watch?v=7LOF7KM7UhY is incorporated into the storing of such data then it should be resistant to any methods current or yet to be imagined.
I’m of course joking but unless someone is from the future, I would take the advice of most of the others have already given. If you don’t want it to get made public don’t store it anywhere that you don’t have 1000% control over. Even the best security can’t foresee everything.
Hi @czikus, I think Anytype is vulnerable to many more attacks than just HNDL. Just have a look at the API authentication code on GitHub. It looks pretty scary to me. And this is just one example. Feel free to browse a bit in the open source repos and discover for yourself.
Can you explain the vulnerability then, because what you say seems a bit hand-wavy. Oh the code looks complicated, then it has vulnerabilities, doesn’t seem like a good argument to me. What stuff did you discover so far?
Yes, we’d love to know more about any vulnerabilities you’ve discovered regarding the API (or anything else). Always looking to improve and patch these things.
I also find it strange that people on the team ask to explain security vulnerabilities on an open forum before looking into it themselves. To me that shows that security is not really taken seriously. But I could be wrong. Just my two cents. The overall product is really cool as note taking app though. Nice work!
Apologies for the miscommunication, when I said that, I actually expected you to DM me. However, I wasn’t clear so that’s my mistake. I’ve hidden your message and have forwarded it to our team to investigate.
We absolutely take security seriously and that can be seen by all the e2ee we have across the product. In the future, you can use this process. However, we do and can make mistakes, which is why we are grateful to anybody who takes the time to bring things to our attention. We’ll keep you posted based on what we find.
@catlike.sambas Thank you for reporting! We acknowledge the problem and have started to work on a fix. It should be available soon on anytype-heart and anytype-ts v0.45.3.
Hi, thanks for the fast response. I think that this issue is a clear example that proves that just adding e2ee across the product does not make a product safe.
Of course making a safe product is a constant battle and it is not easy. Have you ever had your systems audited by a third party? Probably that could give some credibility around the safety aspects of the product.
100% agree. Device-level threats are another clear channel for vulnerabilities that e2ee does very little for. It’s not that we think e2ee is a panacea for all issues, rather I used it as a small example as a response to your point on caring about security. While we have put in a lot of effort thus far, it doesn’t mean we’re without mistakes, of course.
Yes, we’ve been audited by Cure53 and are near completion. We will release the results in the near future once all is ready.
Again, we appreciate you bringing the API bug to our attention. Feel free to ping me directly for any future vulnerabilities you find. Lucky I caught your comment in this old quantum-resistant topic, haha.
.