https://gemini.spam.works/~/emery/
UNIX apostate
From Emery Hemingway to ~pukkamustard/eris
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
From Emery Hemingway to ~pukkamustard/eris
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.
From Emery Hemingway to ~pukkamustard/eris
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
From Emery Hemingway to ~pukkamustard/eris
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.
From Emery Hemingway to ~pukkamustard/eris
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?
From Emery Hemingway to ~pukkamustard/eris
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
From Emery Hemingway to ~pukkamustard/eris
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
From Emery Hemingway to ~ehmry/genodepkgs
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
From Emery to ~adnano/gemini
On Donnerstag, 26. November 2020 17:43:43 CET, roy niang wrote: >> There are lots of guides online to do either of those, and it will >> massively clean up the >> discussions here. > > BTW, your lines are strangely wrapped. > > What's a bottom post?
From Emery to ~adnano/gemini
This is a problem solved many times over. You will need to do better than the Noise protocol, which is the most compelling alternative to TLS. http://noiseprotocol.org/ https://noiseexplorer.com/ https://verifpal.com/ - Formal proofs or GTFO E.