Hail Eris,

The ERIS spec has recently gone through a security review (more details
on that later) and as a result we have some good and bad news. The bad
news is there is a flaw in the ERIS spec that can lead to a leak of
plaintext data. The good news is we think we have a migation and we can
still make breaking changes to the spec without affecting anyone.

To understand the flaw, imagine an ERIS implementation is dereferencing
a URN. The URN refers to a tree of zero depth, that is a single content
block. Imagine that the block depth byte of that URN suffers a bit
flip, it could be a malicous flip, a programing error, or a rogue
high-energy particle. It doesn't matter which bit was flipped, but the
depth is now higher than it should be. The implementation fetches the
block from some external store, and assumes the block is an
intermediate node in the tree. The block is split into pairs of key and
reference, and the requests the next layer of blocks from storage using
those references. But what are those references? The plain text in
interleaved 32-bytes sections! Half of the plain text was just
requested over the network or written to an error log!

The simple fix is to tweak encryption for each level of the tree. Until
now we have used the Chacha20 cipher with a zero block counter and
nonce. By changing the nonce at each level we require the correct block
level for successful encryption and decryption. The proposal is
therefore to set the final byte of the 96-bit nonce to the height of
the tree relative to the bottom layer of content leaves (tree depth is
limited to 255).

Unless there are any objections, we will make this breaking change in
the next draft revision of the spec, and release updated
implementations shortly thereafter.

Cheers,
Emery

Hello,

I have just updated to spec to include this change (https://codeberg.org/eris/spec/commit/26e337186aded9015cbf6811cd615ad3a32c94f2).

As this is a breaking change in the encoding we have adopted the URNs
`urn:erisx3`.

The rendered version is online as 0.4.0-dev: http://purl.org/eris . Note
the new formating. More on that later.

Test vectors as well as the Guile and Nim implementations have been
updated to include this change.

We will release a version 0.4.0 of the specification with this change
and other possible breaking changes. Implementors may wish to wait for
the 0.4.0 release before implementing this change.

Cheers,
pukkamustard


Emery Hemingway <ehmry@posteo.net> writes:

> [[PGP Signed Part:Undecided]]
> Hail Eris,
>
> The ERIS spec has recently gone through a security review (more details
> on that later) and as a result we have some good and bad news. The bad
> news is there is a flaw in the ERIS spec that can lead to a leak of
> plaintext data. The good news is we think we have a migation and we can
> still make breaking changes to the spec without affecting anyone.
>
> To understand the flaw, imagine an ERIS implementation is dereferencing
> a URN. The URN refers to a tree of zero depth, that is a single content
> block. Imagine that the block depth byte of that URN suffers a bit
> flip, it could be a malicous flip, a programing error, or a rogue
> high-energy particle. It doesn't matter which bit was flipped, but the
> depth is now higher than it should be. The implementation fetches the
> block from some external store, and assumes the block is an
> intermediate node in the tree. The block is split into pairs of key and
> reference, and the requests the next layer of blocks from storage using
> those references. But what are those references? The plain text in
> interleaved 32-bytes sections! Half of the plain text was just
> requested over the network or written to an error log!
>
> The simple fix is to tweak encryption for each level of the tree. Until
> now we have used the Chacha20 cipher with a zero block counter and
> nonce. By changing the nonce at each level we require the correct block
> level for successful encryption and decryption. The proposal is
> therefore to set the final byte of the 96-bit nonce to the height of
> the tree relative to the bottom layer of content leaves (tree depth is
> limited to 255).
>
> Unless there are any objections, we will make this breaking change in
> the next draft revision of the spec, and release updated
> implementations shortly thereafter.
>
> Cheers,
> Emery
>
> [[End of PGP Signed Part]]