View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011875 | GNUnet | file-sharing service | public | 2026-10-18 23:40 | 2026-10-18 23:40 |
| Reporter | Jllx | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Summary | 0011875: is there planned evolution of the filesharing protocol to allow other crypto? | ||||
| Description | I'm looking at the gnunet file sharing structure - a merkle tree with 1024oct blocks - 2 types of blocks : iBlock and dBlock (both 1024 oct wide) - iBlock contains a : 25*[Keypasswd(ripemd-160), CypheredBlockHash(ripemd-160)]+ superhash (ripemd-160)+Crc32 the cipher key of dBlock is computed from Keypasswd(ripemd-160) using the first 128b and cipher algorithm is AES => this is normaly enough for quantic attack safety, but this rely only on one cipher algorithm, if this cipher get compromised, the whole network will be unusable or compromised => the block size is small, this create about 1,95% storage overhead. => ripemd is a bit less trustable than recent hash algorithm => I wonder why have a CRC32 + a ripemd-160 : ripemd-160 has a "avalanche" effect : each bit changed shall change about 50% the 160bits making it more safe to detect corruption of the block than a CRC32 (corruption that can be created by transmission error or attacker that try to change some block sequence to inject it's own blocks). So why not saving some space and not have the CRC32, today computer are fast enough to perform hash computation when files were small this wasn't an issue, but with big files, this create lot of wasted space (and more if using recent file storage that add some data integrity like btrfs I wonder if it's not possible to make the protocol more "evolutive" without breaking everthing on long term for exemple have a "metadata block" that contain some information like block size, key derivation algorithm, hash algorithm, passwd length the metadata block is the first block returned (containing something like xattr of unix (without limits)?) the iBlocks are then processed according to the metadata : iBlock structure stay as x*[keyderivationPass[passwdLength], CypheredBlockHash]+superhash the key for the symetric filter is obtained with KDF(keyderivationpass[passwdLength]) allowing the passwd to be of arbitrary size of course searching of a block will have to be adapted to be able to specify the hash function used today, 1ko blocks is rather small and inefficient, 4ko is the standard unix page size this should allow to still be compatible with the current file subdivision, allowing to progressively move to something that can change and allowing to add more cipher to gnunet only the first block have to stay 1ko wide and can be increased using xattr | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-10-18 23:40 | Jllx | New Issue |
