Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Headers #6

Closed
cryptoquick opened this issue Sep 24, 2022 · 2 comments
Closed

Headers #6

cryptoquick opened this issue Sep 24, 2022 · 2 comments

Comments

@cryptoquick
Copy link
Member

Each of the four formatting steps should be configurable as to whether they can be used. They should also be built in as conditionally compiled features.

These options should be tracked, perhaps in a compiletime-generated 4-bit bitmask. This can then be added to the magic number, and also the bech32m filename.

This should also make #5 easier to debug.

@cryptoquick
Copy link
Member Author

We could use a bitmask matrix to indicate whether a storage format is used to encode something. This would allow skipping certain steps if desired. Then, formats can be referred to by their bitmask. Carbonado 0 means no compression, encryption, stream verification, or error correction. Carbonado 15 would be all of them. If we used a byte in a magic number header, that'd also leave room for future formats. Using a varint instead would futureproof this even more.

@cryptoquick
Copy link
Member Author

Bitmask for Carbonado formats c0-c15

Format Encryption Compression Verifiability Error correction Use-cases
c0 Marks a file as scanned by Carbonado
c1 Encrypted incompressible throwaway append-only data streams such as CCTV footage
c2 Rotating public logs
c3 Private archives
c4 Unencrypted incompressible data such as NFT/UDA image assets
c5 Private media backups
c6 Compiled binaries
c7 Full drive backups
c8 ???
c9 ???
c10 ???
c11 Encrypted device-local Catalogs
c12 Publicly-available archival media
c13 Georedundant private media backups
c14 Source code, token genesis
c15 Contract data

Verifiability is needed to pay others for storing or hosting your files, but it inhibits use-cases for mutable or append-only data other than snapshots, since the hash will change so frequently. Bao encoding does not have a large overhead, about 5% at most.

Any data that is verifiable but also unencrypted is instead signed by the local key. This is good for signed compiled binaries or hosted webpages.

Estimated encoding overhead

Encoding Cost Details
Encryption ~200 bytes AES-GCM authenticated encryption
Compression Variable -80% for contracts, -20% for code, +~100 bytes if incompressible
Verifiability ~5% Bao encoding
Error correction 200% 4/8 ZFEC encoding

All formats have a magic number and Carbonado header that includes necessary information for its specific formats.

@cryptoquick cryptoquick changed the title Feature-level formatting optionality Headers Nov 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant