5 ms·
I do not buy the argument against AES. On both ARM and x86 you have side-channel secure hardware implementations of AES.
by legulere 9y ago
I do not buy the argument against AES. On both ARM and x86 you have side-channel secure hardware implementations of AES.
- beefhash 9y agoI assume they're targeting more than just ARM and x86, given they're talking about "truely portable AES implementations" in the README[1]. That said, I'm very inclined to distrust a very young cipher... released by the NSA, no less[2]. Which is an add-rotate-xor cipher[2], for which we already have the more reviewed ChaCha20[3], suggested for TLS 1.3[4]. [1] https://github.com/redox-os/tfs/blob/master/README.rst#faq https://github.com/redox-os/tfs/blob/master/README.rst#faq [2] https://eprint.iacr.org/2013/404 https://eprint.iacr.org/2013/404 [3] https://cr.yp.to/chacha/chacha-20080128.pdf https://cr.yp.to/chacha/chacha-20080128.pdf [4] https://tools.ietf.org/html/rfc7905 https://tools.ietf.org/html/rfc7905
- nightcracker 9y agoChaCha20 would be the right choice here, not SPECK.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- jedisct1 9y agoOr if they really want a lightweight cipher with a small block size, they should consider SPARX, especially since a Rust implementation is readily available: https://github.com/jedisct1/rust-sparx https://github.com/jedisct1/rust-sparx
- jstarks 9y agoHas anyone analyzed SPARX other than the authors? It seems a little early to recommend its use.
- Kubuxu 9y agoSalsa20 and ChaCha20 are faster on modern hardware than built-in AES instructions. AES is just old and complex. As Salsa family and other modern ciphers have shown you don't have to use complex function to achieve security.
- tw04 9y agoSalsa20 and ChaCha20 aren't FIPS140-2 certified (that I'm aware of or can find documented) which is pretty much a basic requirement at this point for anything in the enterprise.
- Kubuxu 9y agoAnd they probably won't for political reasons. Salsa20 was created by DJB who has previously fought with US Gov against encryption export ban and also they have their own suits they prefer you to use (for their own reasons). Here is a reason why you can't trust US Gov for creating secure encryption: https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG
- tw04 9y agoIt doesn't matter if I trust or distrust the US government for creating secure encryption. There are laws in place across a plethora of industries REQUIRING FIPS140-2. If you want to do business in the US, it's a basic requirement. At the end of the day the odds of this filesystem gaining any traction are basically 0. I'm just pointing out that not supporting an encryption algorithm that can meet the FIPS requirement makes it basically a non-starter for any commercial application.
- kuschku 9y ago> At the end of the day the odds of this filesystem gaining any traction are basically 0. I'm just pointing out that not supporting an encryption algorithm that can meet the FIPS requirement makes it basically a non-starter for any commercial application. In the US. In many other countries, it might gain lots of traction.