On Fri, Oct 30, 2015 at 12:11 AM, Daniel Kahn Gillmor
<dkg(_at_)fifthhorseman(_dot_)net> wrote:
But one of our constraints is the OpenPGP use case that streams
decrypted data, like this:
pgp --decrypt <backup.pgp | tar x
It's unlikely that this use case will go away.
Is that constraint really set in stone?
PGP is a complicated system to use and understand for most people and
the more an implementation can do to prevent potential dangers the
better. I think it could be worthwhile of the spec to have security
guidelines for implementers to make dangerous invocations more
difficult.
To use your example, consider the following further examples:
pgp --decrypt --file backup.pgp | tar x
The above is fine. Run two passes over the file, one for integrity,
one for output.
pgp --decrypt < small-backup.pgp | tar x
The above is fine. The file is small and it fits into some predefined
buffer in memory before reaching EOF. Similar to the above: check
before outputting anything.
pgp --decrypt < backup.pgp | tar x
The above is *not* fine, and the user should have to go through hoops
to make it work (for example some kind of --unsafe option, or big
warning pop up box in a GUI application).
In general I think the OpenPGP spec should have more guidelines for
implementors since it's very easy for the user to screw up if the user
is not familiar with intricate details of the system. This is to a
greater extent than other specs, that mostly concern specialists
anyway.
Removing the constraint above, and living in the normal world where
you do 1 pass integrity before decrypting, you can use much more
boring and standard cryptographic constructs, which I personally would
prefer in this case.
Cheers
Björn
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp