References: <c5576d87-71da-977a-4935-969ec720f64c@spacekookie.de>
From: pukkamustard <pukkamustard@posteo.net>
To: Katharina Fey <kookie@spacekookie.de>
Cc: ~pukkamustard/eris@lists.sr.ht
Subject: Re: Introduction of smaller block sizes
Date: Tue, 09 Aug 2022 14:50:55 +0000
In-reply-to: <c5576d87-71da-977a-4935-969ec720f64c@spacekookie.de>
Message-ID: <86a68djumh.fsf@posteo.net>
MIME-Version: 1.0
Content-Type: text/plain


Hi!

I'm a keen follower of the Irdest project and personally interested in
LoRa. Thanks for your mail!

Katharina Fey <kookie@spacekookie.de> writes:

> In the best case Lora radio environment in the case of attempting to
> transmit a standard 1KB ERIS frame over Lora using reasonable framing
> and the maximum permissible 242byte MTU, frame transmission would
> require being split over 5 Lora Messages, which must be separated by
> (at minimum) 2 seconds each. This would require at least 10 seconds to
> transmit any Ratman message regardless of actual size.

What is the relation between ERIS blocks and Ratman messages?

Just to clarify terminology: We don't use the term "frame" in the ERIS
specification. I assume that by frame you mean some content that is
padded by ERIS to block size (1KiB or 32KiB).

> Currently ERIS frames are padded to the nearest 1K block size before
> encrypting. We wish for smaller power of 2 padding options of 512,
> 256, 128 and 64 bytes

64 bytes will not work as in order to be able to build a tree a ERIS
node needs to hold references to at least two children. A reference to a
child node has size 64 byte. With block size 64 byte we will not be able
to encode content larger than 63 bytes.

Also, ERIS encodes some arbirtrary sized content into uniform sized
blocks (currently all either 1 KiB or all 32 KiB) and a read capability
that can be encoded into 66 bytes (or as a URN). In order to decode the
content one needs access to all the blocks AND the read capability.

So to transfer some content smaller than 64 bytes you would need to
transfer 64 bytes of block plus and additional 66 bytes for the read
capability. That's an overhead of over 100%. The argument holds for any
small block sizes with relatively smaller, but still considerable,
overhead.

Security-wise there is also an argument against small block sizes (or
small pieces of content in general). When using convergent encryption
and when the entropy of the encoded content is low, an attacker can
potentially learn the content by simply brute-forcing. This is known as
the Learn-The-Remaining-Information Attack [1;2].

Finally, the block sizes in ERIS were chosen based on common sizes of
content. 32 KiB for large content and 1 KiB for small pieces of
meta-data or annotations. The goal of ERIS is to make such content
available robustly over many transport protocols. ERIS also provides
identifiers for content that are stable over transport protocols and
applications. Using different block sizes for the same content results
in multiple identifiers for the same content. I don't think content
identifiers should be subject to fluctuations at the transport layer.

Imho, a valid argumentation for a smaller block size would be more along
the lines (just an example - It might not make any sense with respects
to Ratman): "Ratman routing tables are encoded with ERIS as they persist
for many hours/days and having persistent identifiers as well as the
ability to distribute them content-addressably (and possibly using other
non-Irdest transports) is important. However, for the most common sized
networks the routing table is about 500 bytes large. It's a considerable
overhead to use almost 100% padding - an ERIS block size of 512 bytes
would be an optimization for such a case."

I think it would be good to understand better how you are using ERIS in
Irdest/Ratman.

Cheers,
pukkamustard

[1] http://purl.org/eris#name-known-attacks-on-convergent
[2] https://tahoe-lafs.org/hacktahoelafs/drew_perttula.html