Viewing profile — ticki_

> The first section in the README is called "Design goals", with 13 items. None of them is "data integrity", and none of them even talks about validating the data or handling any f…

With modern hard disks, no. They work in sectors.

Author here. > I don't know if the authors are here, but if they are - would you comment on fragmentation and the dangers of growing a filesystem past 95-98% full ? Fragmentation i…

The data is summed too.

> A good design would look at the state of the art and use the best techniques available. If the aim was research, then try one new thing, not a thousand. That's what it does: It t…

I meant ChaCha20 ofc. Well, my points still remains. You need to store IVs/keys/etc. which makes it pretty unsuitable for a file system.

TFS was created to speed up the development. The issue is that following the design specs makes it much slower to implement, and prevents a "natural" development (like, you cannot …

> I understand this filesystem is still nascent, but shouldn't data integrity at least be one of the design goals? What makes you think it isn't? It definitely is. In fact, it borr…

ChaCha2 isn't a block cipher. It's a stream cipher, and would thus require storage of IVs ... which, well, is going to expensive space-wise.

I agree. SipHash is certainly strong if you don't know the key.

If you know the key, it is as weak as it gets (as the paper notes too, you can construct collisions easily if the key is known), so I disagree.

Oh, well. What I think of as "cryptographic hash function" is a function resistent to pre-image attack, second pre-image attack, and collision generation. Neither of those are sati…

Please don't. DJB2 is a poor hash function. It's similar to FNV: Entropy only moves upwards, so flipping higher bits doesn't affect lower bits. In other words, you risk mapping `n`…

No, it's not a cryptographic hash function. It's a MAC function. The paper clearly states that it is not collision resistant.

A lot of stuff. SHA256 is very slow, and that's no surprise. It's cryptographic after all. Here's a small list of usecases for non-cryptographic hash functions: - Checksums and err…

In hash tables, you never use cryptographic hash functions. Why? Because they're slower. Take SHA3, which is around 50x slower than SeaHash. That is really really bad for hash tabl…

There's a huge difference between cryptographic and non-cryptographic. Note that blake2 has various length, whereas SeaHash is fixed to 64-bit (although I suppose it's not to hard …

MetroHash's main transformation actually loses entropy, so that's, well, pretty bad. It still passes Smhasher, though.

SeaHash is obviously not cryptographic (nor is SipHash), but I hope it is a secure PRF (i.e. the keys cannot be extracted), and this was the best attack I was able to construct. St…

BLAKE(2) is a cryptographic hash function, SeaHash is not. Even the fastest implementations of BLAKE only gets around 7.8 cycles/byte (hardware might do it twice as fast). SeaHash …