Re: [openpgp] "OpenPGP Simple"

[Phillip Hallam-Baker <[e-mail]>]

On Mar 16, 2015, at 11:05 PM, David Shaw <[e-mail]> wrote:

On Mar 16, 2015, at 10:10 PM, Peter Gutmann <[e-mail]>
wrote:


David Shaw <[e-mail]> writes:

On Mar 16, 2015, at 5:15 PM, David Leon Gil <[e-mail]> wrote:

Partial lengths are really a nuisance to parse.


No argument there...


The whole bizarro sort-of-fixed-point encoding of lengths is a pain (this
is a
cue for Jon to do his "every bit is sacred" dance).  If the format is
revised,
there should be only two lengths, a 16-bit one for almost everything
(keyring
data, signatures, etc), and a 32-bit one for payloads and partial lengths
that
are going to exceed 16-bit lengths.  Length-decoding shouldn't be any more
complicated than:

read tag;
if( tag & length_32_flag )
length = read32();
else
length = read16();


I'm fine with that, but I do want to keep the concept of partial lengths,
as you did above.  People do encrypt things without knowing how large they
are ahead of time.  I'm fine with a restriction (which already exists
today) that only payloads can use partial lengths.


+1

But that 32 bit length really worries me. Just because people can’t send
4GB messages today does not mean that they can’t or won’t in the future. Do
not build OpenPGP around assumptions based on SMTP continuing forever. Use
today is not limited to mail in any case.

If I have a 1TB archive file I am not going to want to break it into chunks
just to encrypt it.


I am not convinced a complete overhaul of the messaging format is
desirable. But if people were going to completely revise the message
format, the field is moving towards JSON for almost everything.

The only thing JSON does not do that is essential for crypto is length
prefixed binary encoding of binary blobs. Base64 encoding is not so bad if
you do it only once. But a 33% penalty for each time a file is wrapped
starts to add up. When folk were suggesting yet another data encoding,
several of us who only want one data model suggested just adding code
points for binary blobs to JSON. It does get the job done.


Again, I am not sure that a complete overhaul is desirable. Just pruning
back the unnecessary features is probably sufficient. But if a change is
made, best to pick something that looks as much like the standard the rest
of the protocol stack above layer 5 is converging on as possible.