Re: V3 secret keys

[[e-mail] ("Hal Finney")]

Ben Laurie writes:
> Hal Finney wrote:
> > Daniel Nagy writes:
> >> I sincerely hope that this whole mess will be cleaned up with V5, where
> >> there seems to be a consensus not to implement encrypted private key packets
> >> at all, but put unencrypted private key packets into integrity protected
> >> symmetrically encrypted packets instead.
> > 
> > I haven't participated in the recent discussion, partly because I think
> > it is a little premature until we get the current spec put to bed.
> > 
> > I am not sure I like this idea.  We'll need to retain the old mechanism
> > for many years at least, requiring us to support yet another set of
> > incompatible mechanisms.  And I don't know if the new proposal really
> > simplifies things much.
>
> Surely you should already support this method?

If you mean, can you send a secret key around in an encrypted file,
and then decrypt and import it in a single operation... yes, there's
a good chance that works.  However some of the more advanced ideas,
like having multiple secret keys in a single file, each encrypted in a
different packet, I have no idea what would happen, it is not something
we have tested to my knowledge.

> > Complications have been pointed out regarding sending multiple keys
> > encrypted with different passphrases, requiring us to explicitly support
> > multiply-concatenated symmetric-encryption & SKESK packets, which is
> > not necessary at present.
>
> It isn't?

No, I don't know of any application for that.

> > It might require us to bite the bullet and
> > clarify exactly what sequences of packets are legal, with possible
> > backwards-compatibility problems.
>
> Hmm. My implementation will eat _any_ sequence of packets.

So what do you do if you decrypt a file and find a sequence of encrypted
packets?  Or perhaps some packets signed, some encrypted, some both, all
concatenated? Do you concatenate the results into a single output file
(erasing the boundaries between the plaintexts, as well as information
about what was signed and what wasn't); do you concatenate them along
with some header information to identify where each piece starts and ends
(which won't be reliable due to spoofing); do you output each piece to
separate output files?  Or ask the user what he wants to do?

This kind of operation introduces considerable complexity in terms of
providing a reasonable interface.  We generally assume we are dealing
with a single message consisting of one or more PKESK/SKESK packets with
an encrypted packet, or a similar signed message.  Once you go beyond
this and try to deal with arbitrary sequences of packets it becomes
highly problematic to make sure the user is getting the full benefit
from the cryptography.  If you have a custom program which is using this
for internal, program-to-program communication, then go ahead and knock
yourself out, use the data structures as you wish.  But for person to
person communication I think it is difficult and often unwise to try to
deal with arbitrary sequences.

Hal Finney