On 9/21/22 11:56, Jeff Burdges wrote: > > I've a friend using ERIS https://inqlab.net/projects/eris/ which is > based on https://grothoff.org/christian/ecrs.pdf 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 > >
