I have been thinking a lot about maidsafe’s use of AES as well. I want this project to succeed, and it seemed odd to me that AES was picked as a part of its core encryption. Everyone involved here seems very knowledgeable on it’s issues, and the thing is we already have a great alternative. I have been discussing this with a friend of mine, who deserves a lot of the credit for the text below and might decide to join the conversation, and thought I should share our discussion here. I have also mentioned this to @dallyshalla previously.
I fully acknowledge that my knowledge of Maidsafe’s code is incomplete and based only on the documentation I have cherry picked to read so far, or from talk’s I have heard.
AES (Rijndael 128/192/256) is an industry standard and provides reasonable levels of security. It’s fine for your banking, entering your credit card number, etc. But when looking at ciphers for something new that is designed to be as secure as possible, and intended to last a long time, it is a poor choice. The algorithm/standard is open to biclique and related-key attacks. AES 128 was compromised by a biclique attack. 192 and 256 have been compromised by related-key attacks. It is absolutely true that the attacks were under controlled circumstances, and it would be nowhere near as easy to attack the cipher in the wild, but AES was compromised nonetheless. These issues exist, and will become increasingly easier to exploit over time (something that Maid plans on being around for). So, that being state, I now think that it would be really valuable here, as context on the issue, to take a moment to look back at why Rijndael was picked for AES in the first place:
During the AES competition, three major algorithms emerged; Rijndael, Twofish, and Serpent. Twofish is nice, but represented the middle ground for security, and has since experienced a lack of adoption for adequate testing. So, Rijndael and Serpent. Rijndael had all of the above issues but was specifically chosen because, while acknowledged to be less secure even at the time, it performed far better on late 90’s hardware than Serpent. This was important because the government was looking for an algorithm to replace DES, and work on every device. Rijndael worked on 90’s desktops, laptops, servers, etc at reasonable speeds. The above security concerns were also computationally infeasible at the time so, from a late 90’s standpoint, both algorithms were equally secure.
Serpent however, is a much better choice today. The performance issues are negligible. You can do full disk encryption with Serpent (with LUKS for example), and only have a few mb/s difference between an encrypted and non encrypted disk. AES uses 10, 12, or 14 rounds of transformation (depending on key size), while Serpent uses 32 rounds. Currently, all known attacks on Serpent are computationally infeasible. While AES has been compromised in its entirety, the closest anyone has come to compromising Serpent is a theoretical paper in which 12 of the 32 rounds could be broken in a controlled environment.
AES has only been compromised in a controlled environment to the best of our knowledge, and it is perfectly reasonable for most forms of communication. It is also a very important standard, so most programs use AES to still be compatible with anything it needs to communicate with. The issue is there is a much better algorithm out there, which has never been compromised, and which provides far more security. When designing something from scratch with security in mind, there is very little reason to use AES over Serpent. People use AES to maintain compatibility with legacy systems, and because it won the AES competition… but without looking at Why it won. MAID is about creating a new internet that fixes the flaws of the old one, improves on it, and becomes a decentralized foundation that lasts for a very long time to come. If you are taking the future-looking stance on security and strength of the protocol, AES is not the right choice. Serpent is currently the best we have when it comes to future expected security, with AES becoming more and more likely compromised going forward. As a decentralized system it might be hard for Maid to make fundamental protocol changes in the future, I don’t know enough to be sure, but assume it’s much the same way you can’t update TCP/IP or DNS to deal with new security realities. Instead they need to be replaced. These new ideas are not immune to how people adopt standards. Bitcoin’s code base is also expected to solidify, pushing modifications up a layer just the same way we layer on top of tcp/ip.
That is the broad strokes of my concern. Specifically the application could use the serpent-xts-plain64 serpent cipher, with 512b keysize, and the whirlpool hash, for storage security.
It’s important to resist the urge to make your own crypto for fundamental security, unless there is a really good reasons, because it can’t have the same level of extensive academic testing and review that existing crypto has, something I’m sure of course you are all well aware of.
I would also recommend taking a look at this paper, discussing topics around the selection of AES, written by Bruce Schneier: https://www.schneier.com/paper-twofish-final.pdf For some context to the paper, Bruce Schneier designed all the 'fish block ciphers. That paper is a comparison of the three AES finalists, and goes over the ‘serpent vs rijndael’ argument. Some highlights are the chart on page 4 showing the security levels of the ciphers, and sentences like this: “We believe that the results of the straw poll at the Third AES Candidate Conference reflected this dichotomy: those that thought security was paramount chose Serpent, while those more concerned with performance chose Rijndael.” And this paper is even before several of the now known possible academic setting compromises in Rijndael were found.
The days of the performance issues with Serpent are gone, this was all from a late 90’s perspective. I use Serpent for my laptops full disk encryption and have no visible performance loss. Truecrypt even offered a combination: Serpent within Twofish within AES. And even with all three, the performance impact was tiny. Which also makes the point that if maid wanted to keep the name and comforting marketing of AES, then while unnecessary, something like AES+Serpent would completely work (or even better Serpent within Twofish). These are very well known and trusted protocols in the crypto world; it would not be an issue.
Sorry for the wall-of-text, that’s something I tend to do. Please take a look and let me know what your thoughts are. I really want Maid to succeed in the long term, and this is a big concern for that to happen.
-Travis