Mailing List Archive

next AE cipher COLM?
Would it make sense to consider
COLM for being the next authenticated encryption algorithm?

COLM v1 is a finalist of
https://competitions.cr.yp.to/caesar-submissions.html
and Christian Forler claims
(around https://media.ccc.de/v/34c3-9142-resilienced_kryptographie#t=2375)
that it is single parse and has better general properties
than OCB or EAX mode.

In addition there is patent claim for the used PMAC construction
https://en.wikipedia.org/wiki/PMAC_(cryptography)

Best,
Bernhar

--
www.intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Re: next AE cipher COLM? [ In reply to ]
On 17/05/18 14:42, Bernhard Reiter wrote:
> Would it make sense to consider
> COLM for being the next authenticated encryption algorithm?

Given the shortage of manpower in the OpenPGP community, is it not more
advisable to stick to algorithms with a few miles on the clock, such as
GCM, even if they may not be strictly ideal? There will never be an
ideal encryption algorithm after all, just ones with known problems and
ones with unknown problems... ;-)

--
Andrew Gallagher
Re: next AE cipher COLM? [ In reply to ]
Yes I prefer GCM or OCB - both well-studied.

There's an updated RFC draft on OCB. I haven't seen yet an RFC defining how to use OCB in CMS - but technically it would be no different from GCM (just need to figure what OID to assign to it ;-).

Sent from my test iPhone

> On May 17, 2018, at 10:48, Andrew Gallagher <andrewg@andrewg.com> wrote:
>
>> On 17/05/18 14:42, Bernhard Reiter wrote:
>> Would it make sense to consider
>> COLM for being the next authenticated encryption algorithm?
>
> Given the shortage of manpower in the OpenPGP community, is it not more
> advisable to stick to algorithms with a few miles on the clock, such as
> GCM, even if they may not be strictly ideal? There will never be an
> ideal encryption algorithm after all, just ones with known problems and
> ones with unknown problems... ;-)
>
> --
> Andrew Gallagher
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: next AE cipher COLM? [ In reply to ]
On Thu, 17 May 2018 16:47, andrewg@andrewg.com said:

> advisable to stick to algorithms with a few miles on the clock, such as
> GCM, even if they may not be strictly ideal? There will never be an

I wrote it several times over the last days: We have working and
interoperable implementations of the new AEAD mode [1]. Along with a
very well optimized implementation in Libgcrypt master. No need to open
that case again. It is unfortuanate that we need to have algorithm
preferencees and to define two of them but that is required to avoid a
patent trap. Adding another patented algorithm with zero experience in
the field is not helpful.

And please don't mention GCM - counter based algorithms are way too
brittle for solid cryptography. Remember the RC4 lessons.


Salam-Shalom,

Werner


[1] Ribose NetPGP (rnp), GnuPG 2.3, openpgp.js
--
# Please read: Daniel Ellsberg - The Doomsday Machine #
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: next AE cipher COLM? [ In reply to ]
> And please don't mention GCM - counter based algorithms are way too
> brittle for solid cryptography. Remember the RC4 lessons.

To say nothing of the implementation difficulty. The more complex the
algorithm, the less the chance it'll be implemented correctly. As
someone who's implemented GCM a couple of times, it's not a simple mode.
It's tremendously fiddly. Complicated code leads to complicated
failure modes and testing difficulties.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: next AE cipher COLM? [ In reply to ]
As a cryptographer and a mathematician, I find both GCM and OCB modes quite fine. In general, IMHO “counter based algorithms” (assuming you mean CTR mode) are the best performance-wise, and applicability-wise. Having formal mathematical proofs of correctness doesn’t hurt either (or did you notice?).

I fail to see any similarities with RC4, and cannot guess what lessons you might be referring to. Although, if you found a weakness in GCM mode - by all means, please share it with the wider audience. Or is it that you find it more difficult to code than ECB?

Any cryptographic software is “fiddly” if you pay (or if you *don’t* pay!) enough attention.


On May 17, 2018, at 14:16 , Robert J. Hansen <rjh@sixdemonbag.org<mailto:rjh@sixdemonbag.org>> wrote:

And please don't mention GCM - counter based algorithms are way too
brittle for solid cryptography. Remember the RC4 lessons.

To say nothing of the implementation difficulty. The more complex the algorithm, the less the chance it'll be implemented correctly. As someone who's implemented GCM a couple of times, it's not a simple mode. It's tremendously fiddly. Complicated code leads to complicated failure modes and testing difficulties.
Re: next AE cipher COLM? [ In reply to ]
Thanks for documenting the argument.
I believe it is worth documenting it, because if a switch is done,
it is done for many years to come.

Am Donnerstag 17 Mai 2018 19:27:04 schrieb Werner Koch:
> Adding another patented algorithm with zero experience in
> the field is not helpful.

The patent situation on COLM seems to be better than the one on OCB.

For OCB Mr. Rogaway still holds patents (with several grants to "Open Source"
licenses, but it is not completely clear what this means).

For COLM and the involved PMAC he and John Black have waived their patent
rights.

Bernhard


--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Re: next AE cipher COLM? [ In reply to ]
> Although, if you found a weakness in GCM mode - by all means, please share
> it with the wider audience.

Christian Forler and Rüdiger Weis report on problems with GCM
around 28:00 in their 2017 CCC talk here:
https://media.ccc.de/v/34c3-9142-resilienced_kryptographie#t=1748
where their cite three papers.


--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Re: next AE cipher COLM? [ In reply to ]
On Fri, 18 May 2018 04:16, uri@mit.edu said:

> I fail to see any similarities with RC4, and cannot guess what lessons
> you might be referring to. Although, if you found a weakness in GCM

RC4 has so many preconditions for safe use that it has never been used
in a safe way. But it was easy to implement.

GCM is of course easier to use and way better designed but still the
reuse of the IV with the same key leaks the plaintext. And it is the
most complicated mode to implement which I consider bad for security.

OCB is a clean and simple design which does not leak the plaintest on
accidental IV reuse.


Shalom-Salam,

Werner



p.s.
I have received questions on performance. Here is what Libgcrypt master
yields on a i5-2410M using AES (enc has additional data):

| nanosecs/byte mebibytes/sec cycles/byte
CBC enc | 1.79 ns/B 531 MiB/s 4.13 c/B S/MIME
CBC dec | 0.28 ns/B 3472 MiB/s 0.63 c/B
CFB enc | 1.77 ns/B 538 MiB/s 4.08 c/B OpenPGP (rfc4880)
CFB dec | 0.27 ns/B 3562 MiB/s 0.62 c/B
CCM enc | 1.80 ns/B 531 MiB/s 4.13 c/B
CCM dec | 2.07 ns/B 462 MiB/s 4.75 c/B
EAX enc | 1.79 ns/B 531 MiB/s 4.13 c/B rfc4880bis
EAX dec | 2.07 ns/B 461 MiB/s 4.75 c/B
GCM enc | 0.68 ns/B 1413 MiB/s 1.55 c/B
GCM dec | 0.95 ns/B 1008 MiB/s 2.18 c/B
OCB enc | 0.28 ns/B 3360 MiB/s 0.65 c/B rfc4880bis
OCB dec | 0.30 ns/B 3148 MiB/s 0.70 c/B

--
# Please read: Daniel Ellsberg - The Doomsday Machine #
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: next AE cipher COLM? [ In reply to ]
If nonce reuse is a concern (which really shouldn't apply to OpenPGP or S/MIME, because each message should get its own unique random symmetric key - so the likelihood of collision is rather low), there's AES-GCM-SIV that's misuse-resistant (again, comes with security proofs).

OCB had been released to some open source, and if need be - one can ask Phil Rogaway to make an explicit statement on its use in GnuPG (my gut feeling is he'd be happy to permit it). And yes, OCB shows excellent performance even on CPUs without AES-NI and PCMUL.

P.S. Did but look at COLM - swamped with real work (plus: if I find a problem - it means it's broken; if I find no issue - it means nothing). COLM may be the best thing since sliced bread, but I personally prefer something with a longer history.

Sent from my test iPhone

> On May 18, 2018, at 04:22, Werner Koch <wk@gnupg.org> wrote:
>
> On Fri, 18 May 2018 04:16, uri@mit.edu said:
>
>> I fail to see any similarities with RC4, and cannot guess what lessons
>> you might be referring to. Although, if you found a weakness in GCM
>
> RC4 has so many preconditions for safe use that it has never been used
> in a safe way. But it was easy to implement.
>
> GCM is of course easier to use and way better designed but still the
> reuse of the IV with the same key leaks the plaintext. And it is the
> most complicated mode to implement which I consider bad for security.
>
> OCB is a clean and simple design which does not leak the plaintest on
> accidental IV reuse.
>
>
> Shalom-Salam,
>
> Werner
>
>
>
> p.s.
> I have received questions on performance. Here is what Libgcrypt master
> yields on a i5-2410M using AES (enc has additional data):
>
> | nanosecs/byte mebibytes/sec cycles/byte
> CBC enc | 1.79 ns/B 531 MiB/s 4.13 c/B S/MIME
> CBC dec | 0.28 ns/B 3472 MiB/s 0.63 c/B
> CFB enc | 1.77 ns/B 538 MiB/s 4.08 c/B OpenPGP (rfc4880)
> CFB dec | 0.27 ns/B 3562 MiB/s 0.62 c/B
> CCM enc | 1.80 ns/B 531 MiB/s 4.13 c/B
> CCM dec | 2.07 ns/B 462 MiB/s 4.75 c/B
> EAX enc | 1.79 ns/B 531 MiB/s 4.13 c/B rfc4880bis
> EAX dec | 2.07 ns/B 461 MiB/s 4.75 c/B
> GCM enc | 0.68 ns/B 1413 MiB/s 1.55 c/B
> GCM dec | 0.95 ns/B 1008 MiB/s 2.18 c/B
> OCB enc | 0.28 ns/B 3360 MiB/s 0.65 c/B rfc4880bis
> OCB dec | 0.30 ns/B 3148 MiB/s 0.70 c/B
>
> --
> # Please read: Daniel Ellsberg - The Doomsday Machine #
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: next AE cipher COLM? [ In reply to ]
Hi,

On Fri, 2018-05-18 at 10:56 +0000, Uri Blumenthal wrote:
> which really shouldn't apply to OpenPGP or S/MIME, because each
> message should get its own unique random symmetric key
Mind you: people use OpenPGP not only for email but also for backups.

That's why two-pass schemes are not suitable, because you cannot stream
large amounts of data. There are still one-pass schemes which make
nonce reuse less fatal as with AES-GCM.

Cheers,
Tobi

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: next AE cipher COLM? [ In reply to ]
Hi,

On Fri, 2018-05-18 at 10:12 +0200, Werner Koch wrote:
> OCB is a clean and simple design which does not leak the plaintest on
> accidental IV reuse.
>
It may not leak the actual plaintext right away but it degenerates to
ECB which some people consider to be equally bad.

Cheers,
Tobi

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel