5 ms·
It should split it in chunks and authenticate each one of them. Then the worst attack would be the ability to truncate the file, and it could be at least detect
by shinigami 8y ago
It should split it in chunks and authenticate each one of them. Then the worst attack would be the ability to truncate the file, and it could be at least detected.
Unfortunately this is not supported by the PGP spec, or any other well established spec.
- tptacek 8y agoWhat's happened here is that GPG has used the OpenPGP spec as excuse to support extremely insecure default behavior. In reality, GPG can simply buffer and check before writing to stdout, and, in the rare cases where messages are too large to buffer, a flag can be used to override the secure default.
- rocqua 8y agoIf the message is too large to buffer, one might also first just decrypt and stream the plaintext into sha-1. Once the MDC clears, you can just decrypt again, this time writing to stdout.
- tedunangst 8y agoThis is difficult if the input is a nonseekable stream, but that doesn't excuse producing bad output.
- tptacek 8y agoThat's why I didn't suggest it, but to be fair, you could tee the stream into an intermediate file for a two-pass scheme.
- shinigami 8y agoI agree they should have done that as a stopgap measure, but we should push for security in all cases (e.g. streaming AEAD with STREAM or CHAIN https://github.com/miscreant/miscreant/wiki/STREAM https://github.com/miscreant/miscreant/wiki/STREAM )
- tptacek 8y agoI'm not super psyched to see 1990s crypto vulnerabilities used as an opportunity to promote hipster schemes that literally nobody uses. Virtually all modern cryptosystems handle this problem already.
- shinigami 8y agoAEAD was also a hipster scheme that literally nobody used. That's the whole point. In Twitter you even linked to Adam Langley's post where he suggests something exactly like STREAM/CHAIN! Which modern cryptosystems handle this problem? Tahoe-LAFS is the only one that comes to mind. Not being snarky here, I'm genuinely interested in knowing this.
- cyphar 8y agoModern TLS uses AEAD in the form of ChaCha20-Poly1305 as well as AES-GCM. I believe that the current standards in AEAD for ciphers are GCM-mode, EAX-mode and OCB-mode (CCM-mode is also used but only because it has no patents while OCB does -- CCM is more complicated and doesn't have some nice properties that OCB has).
- shinigami 8y agoYes, but that's an online protocol. The problem here is data at rest...
- cyphar 8y agoAll of the cipher suites I mentioned can be used with at-rest data (including ChaCha20-Poly1305, and AES-{GCM,EAX,OCB}), which means that there's nothing stopping PGP from adding support for them. But since you asked, the offline backup software restic[1] uses AEAD (though it's a mix of AES-256-CTR and Poly1305 rather than AES-GCM[2] -- but it's still an AEAD construction). I also recently started working on a paper-backup project, and used ChaCha20-Poly1305 over PGP because of the lack of AEAD (and also because it is vulnerable to surreptitious forwarding -- something that AEAD also solves[3]). There are distinctions between online and offline protocols (mainly related to PFS), but whether or not AEAD-capable cipher suites can be used is not one of them. [1]: https://restic.net/ https://restic.net/ [2]: https://blog.filippo.io/restic-cryptography/ https://blog.filippo.io/restic-cryptography/ [3]: https://www.usenix.org/legacy/publications/library/proceedings/usenix01/full_papers/davis/davis_html/index.html https://www.usenix.org/legacy/publications/library/proceedin...