[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Christian Grothoff
Subject: Re: AEADs
Date: Wed, 21 Sep 2022 13:47:49 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0

On 9/21/22 11:56, Jeff Burdges wrote:
> I've a friend using ERIS which is
> based on and someone audited.
> It does some signature check instead of using an AEAD, which maybe fine,
> and maybe better for encryption-at-rest, about which they seemingly
> care, but maybe also leaks something via side channels if done wrong,
> like maybe if decryption occurs first.

Eh, I don't quite find much about signatures in the ERIS spec using a
casual read. As far as ECRS is concerned, the only signatures it uses
would be the ones from the (optional) use of signatures with namespaces,
which is _exactly_ the same cryptography we use in GNS and in fact the
plan for about the last decade has been to eventually transition to
using GNS records instead of the same cryptographic ideas but without
interoperability for no good reason (other than history...).

For the data, ECRS only uses hashing and symmetric cryptography, so the
only place where we have (GNS-like) signatures is when users 'sign' that
they (pseudonymsly) published files in their namespace.

> Can anyone give me some background on what this stuff is really for? 
> Why the encryption-at-rest appears?

The encryption-at-rest is mostly for caching (including partial caching)
of data by nodes that don't have the decryption key. Historically, it
was also intended to avoid having to re-encrypt, but these days that
itself would be a silly reason given the speed of symmetric encryption.

> And:  Why does it not use an AEAD like chacha20-poly1305?

For ECRS: because it predates Salsa20 by about 5 years. Also, AES seems
to work just fine for this, and AFAIK still has more widely available HW
support. But beyond legacy and maybe a bit performance, I don't see a
technical reason. Oh, and ECRS doesn't need an AEAD as the convergent
encryption inherently provides for the integrity check. So with
convergent encryption, an authentication tag would just bloat the
transmission size. In non-convergent mode, that'd be another story.

> I know less than I should about encryption-at-rest, just that it's
> historically fucked up as much as other things, but less studied than 
> networking.
> Jeff

reply via email to

[Prev in Thread] Current Thread [Next in Thread]