Excerpts from pukkamustard's message of April 25, 2022 2:14 am:

> What you propose is to only use the convergence secret at level 0 - at
> leaf content blocks:
> 
> ENCRYPTION_KEY := Blake2b(CONTENT, key = CONVERGENCE_SECRET)
> ENCRYPTED_CONTENT_BLOCK := ChaCha20(CONTENT, ENCRYPTION_KEY, NONCE)
> 
> And for intermediary node blocks the unkeyed Blake2b function is used
> (convergence secret is not used):
> 
> ENCRYPTION_KEY := Blake2b(CONTENT)
> ENCRYPTED_NODE_BLOCK := ChaCha20(CONTENT, ENCRYPTION_KEY, NONCE)
> 

Hello list

I have a proposal to consider for the erisx3 encoding standard. Before
noticing the problem with decoding trees at the incorrect depth our reviewer
raised an issue that URNs are un-verifiable. Corruption of URNs during
copy-pasting or by an attacker is undetectable without concluding that a
block reference cannot be retrieved. I believe there is a fix that would
solve this problem.

In the current standard there are two essentially different hash functions:
- BLAKE2b with an 128-bit output size and a 128-bit salt. The output of this
  function is a block *key*. Anyone with the key can encrypt or decrypt the
  block, but the key can only be generated by having both the block content
  and the salt. Keys cannot be reliably verify a block, because there is

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

On Sunday 10 October 2021 18:18:43 CEST, pukkamustard wrote:
> What was the use-case you had in mind? And could the problem you
> describe solved in other ways?

My use-case would be some application or system service that produces or
consumes data optimized for ERIS, such as file-system archives or
memory snapshots.

I think you are right that what I've suggested is ambiguous and
unnecessarily complex. What I want is to be create and access blocks
without any padding, which would be possible if an application has
access to a raw block interface. I think this would be reasonable in a
few cases, but these "raw" blocks would not be representable with URNs.

As a systems programmer I am a little bothered by the use of padding
blocks for data that is aligned to an ERIS block size. In the worst
case, a 32KiB blob would be encoded using 96KiB, one block of data,
one block of padding, and one block of Merkle tree.

I propose that a blob of data with a length aligned to its encoding block
size should omit padding if the last byte of the blob is not '0x80'. If
the last byte of the last block is '0x80', then this final byte is
treated as padding. If the final byte of the blob is '0x80', then a block
with byte '0x80' followed by zeros is appended as padding (as usual).

Would this be sufficiently unambiguous?
Emery

On Monday 27 September 2021 10:41:22 CEST, pukkamustard wrote:
> Applications are RECOMMENDED to use a block size of 1KiB for content
> smaller than 16KiB and a block size of 32KiB for larger content.

Yes, this section looks good to me.

E.

On Sunday 26 September 2021 13:13:42 CEST, pukkamustard wrote:
> The Tox bot used for uploading is this here:
> https://git.sr.ht/~ehmry/upload_bot.
>
> I also just spotted an interesting patch on block size choice:
>
> https://git.sr.ht/~ehmry/upload_bot/commit/1f4cf19a6a6ed1313efb7f8dccfdf5f94e874ec2
>
> A concise recommendation for block size is an open TODO in the spec
> (http://purl.org/eris#_block_size). 
>
> Emery, what's the rationale behind the block size choice in the bot?
> Could that be used as a recommendation in the spec?

Hello list,

This weekend at the CCC Dresden annual Datenspuren conference there was
a talk on ERIS. The spec itself is a better explanation of ERIS, but I
tried to give a little background and some potential use-cases.

https://media.ccc.de/v/ds21-116-eris-encoding-for-robust-immutable-storage
https://datenspuren.de/2021/

Cheers,
Emery

Hello list,

I added a utility to the Nim eris_utils package for encode and decoding
files of ERIS blocks. Its quite simple, the block files have an small
header followed by an concatenation of blocks, each of the same size.

Its not very fast, but is effectively a simple encryption and decryption
utility. Multiple blobs can be packed into the same block file and
retrieved by the appropriate URN.

https://git.sr.ht/~ehmry/eris_utils/commit/0.3.0

Cheers,
Emery

I've stopped working on this project and made a short write-up to explain
why:

https://portal.mozz.us/gemini/gemini.spam.works/~emery/devlog/sigil-report.gmi
gemini://gemini.spam.works/~emery/devlog/sigil-report.gmi

Cheers,
Emery