Restic Cryptography
blog.filippo.io
blog.filippo.io
It's not pointless. It facilitates 32-bit limbs¹, which are simpler to implement than 26-bit limbs. (And faster on modern intel processors. My implementation² beats both libsodium and donna by a slight margin.)
If you use 26-bit limbs (as they probably do like everyone else), it is still not pointless: it's the only way to conform to official tests vectors and other Poly1305 implementations, making their implementation more reliable than it would be without them.
It's also not dangerous, as DJB himself proved in his paper —unless one is uncomfortable with those security margins?
[1]: http://loup-vaillant.fr/tutorials/poly1305-design (search "Restricting R")
[2]: http://loup-vaillant.fr/projects/monocypher/
---
I can't fathom why they chose AES over Chacha20, though. Do they plan to rely on bit slicing? Chacha20 would be much simpler than that, and faster too. And if they absolutely want random nonces, they could have just used XSalsa20. (New projects can now use XChacha20, but that may not have been reasonable until a few months ago.)
I was under the impression was GCM was one of the better AES modes. Why is it awful?
I whatever I was developing was open source (any project under an OSI-approved license gets a patent grant), I would use OCB mode, which is not only quite easy to get right, but also friggin fast.
But hey: Don't trust me. Trust Matthew D Green:
> GCM. Galois Counter Mode has quietly become the most popular AE(AD) mode in the field today, despite the fact that everyone hates it. The popularity is due in part to the fact that GCM is extremely fast, but mostly it’s because the mode is patent-free. GCM is ‘on-line’ and can be parallelized, and (best): recent versions of OpenSSL and Crypto++ provide good implementations, mostly because it’s now supported as a TLS ciphersuite. As a side benefit, GCM will occasionally visit your house and fix broken appliances.
> Given all these great features, you might ask: why does everyone hate GCM? In truth, the only people who hate GCM are those who’ve had to implement it. You see, GCM is CTR mode encryption with the addition of a Carter-Wegman MAC set in a Galois field. If you just went ‘sfjshhuh?’, you now understand what I’m talking about. Implementing GCM is a hassle in a way that most other AEADs are not. But if you have someone else’s implementation — say OpenSSL’s — it’s a perfectly lovely mode.
-- Matthew D Green [1]
[1]: https://blog.cryptographyengineering.com/2012/05/19/how-to-c...
If you don’t care about a built in MAC, would you recommend CTR? OCB?
The user wants something that works reliably. If it's hard to implement, confidence decreases. You can compensate with external audits, but those are expensive.
> If you don’t care about a built in MAC, would you recommend CTR? OCB?
You almost always care about built in MAC. If you don't authenticate your data, you will most likely run into trouble. And if you really don't care, I'd rather sidestep the CTR vs OCB vs WTF entirely by using Chacha20 (fast without dedicated hardware, naturally immune to timing attacks, dead simple to implement).
(In the general case, I'd recommend Chacha20 + Poly1305 constructions.)
If you don't have any very good reasons to use CTR (encrypting lots of data with the same key) you.probably shouldn't.
The probability of collision, for 2^R random values of N bits is about 2^(2R-N).
Lets' assume you want a probability of collision of less than 2^-64 (I think this is negligible enough). With 192 bits, this allows up to 2^64 nonces, which is quite hard to exceed in practice.
128 bits however only support up to 2^32 random nonces per key (a few millions). Some applications may exceed this threshold, but this is a backup we're talking about. You probably won't update it more than a million times in your lifetime, which most likely will span less than 30 thousand days from now.
Plain and simple, there is just more room to make a grave mistake.
If you're implementing an entire AEAD construction, like GCM or EAX, from scratch, then yes. Don't do that. You probably are safer composing CBC and HMAC than you would be writing your own EAX.
But if your library exports an EAX, using it is almost certainly a huge security win over DIY authenticated encryption, even if you can remember the order of operations properly.
GP is asking about mistakes that could happen on AES-GCM that won't happen with AES-CTR+HMAC.
I'm no crypto expert, but I'd say there are more opportunities of messing up with AES-CTR+HMAC like forgetting to MAC the IV.
Meanwhile PubNub is using a hard coded IV on every message in ECB and CBC modes :)
https://github.com/pubnub/javascript/blob/master/src/core/co...
In particular: you can easily end up with AE w/o AD by doing DIY ETM, and end up with serious exploitable bugs.
---
Another I have personally seen was using the session key for a Wegman Carter hash (such as Poly1305). I received an email suggesting I do just that in Monocypher, to avoid using up the beginning of the key stream. Didn't realise why this would lead to instant key recovery.
I have since littered my manual with scary tales of total annihilation of security.