On Mon, Jul 03, 2017 at 06:41:11PM +0200, Werner Koch wrote:
On Mon, 3 Jul 2017 18:00, sandals(_at_)crustytoothpaste(_dot_)net said:
Were there opinions on this proposal? Do people like it, dislike it,
I have an opinion on your proposal but wanted to give others time to
reply first ;-). I have had too many other open tasks this year so that
my editorial work was too much delayed, I am sorry for this.
I have two points, briefly:
1. The prior discussion showed that it will be hard to find a common
conclusion on what algorithm to use. Thus instead of having one
fixed algorithm, I will propose a modification to make the new packet
format extensible. I know that this had a lot of drawbacks and
having only one algorithm would be far better than a bunch of
algorithms which we may all need to implement. But the advantage of
allow other algorithms will give the implementers more options to
to show in practice the advantages of different algorithms.
Yes, I tend to agree. Did you feel the existing extensibility mechanism
in my proposal (cipher algo, AEAD algo, chunk size) was insufficient or
did you have something else in mind?
2. We really should have a way to early detect a corrupt message - not
necessary an attack but for example a bit flip somewhere on the
channel. Inserting a running checksum (say, every 1GiB) would solve
this. Obviously this depends on the algorithms, so that the existing
cipher state can be used for such a checksum. A hackish way to that
could be to take the internal state of the algorithm, hash it and
insert it into the stream. A cleaner solution would require several
concatenated cipher streams.
I think my proposal actually implements that. Since my chunk proposal
contains the chunk index (basically, an incrementing counter), as long
as we have the key, we can immediately tell if any chunk is corrupt
simply by knowing the chunk size and authentication tag length. That
allows random-access to data if, for example, you know that all of your
data is uncompressed tar archives.
If we want something simpler in addition, we could reuse the CRC24 as
most implementations will require it for the ASCII armor format.
--
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp