i still don't get why people use elliptic curves instead of diffie-hellman since you can use it for public keys too. the index calculus cryptanalytic method appears to apply for the usage of F_q where q = pn for some prime p. it appears that if q is a large prime and q - 1 is divisible by a large prime, that covers the two biggest error cases
17
Replies
52
Boosts
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
ChaCha is the basis of the BLAKE hash function, a finalist in the NIST hash function competition, and its faster successors BLAKE2 and BLAKE3.
finally this all makes sense to me
learning about checksums. i don't like em
MD5 was designed by Ronald Rivest in 1991
does this guy literally do anything other than backdoors
There is a long list of cryptographic hash functions but many have been found to be vulnerable and should not be used.
i'm fucking amazed nobody has ever brought up the idea that checksums might be different for the purpose of integrity checking vs cryptographic signatures
@hipsterelectron
For the purpose of an integrity check it would actually be great if the checksum differences only slightly is the change in data is small
@realn2s i was thinking about this with i believe @heptapodEnthusiast and we were both kind of unsure how to achieve collision resistance without indifferentiability but i am pretty sure i figured out a cheat code for this and it is basically to retain the entire tree of hash computations at all times, and then invent a tree hash for directory trees:
for file hashes, use a tree hash like BLAKE3 (i'm making some tiny changes personally) and just retain the entire hash computation tree. this will take something like
C * log^2 nspace forC= chunk size andn= number of chunksfor directory hashes, we need two components:
- something to mix together the top-level checksum from the entry's content with the entry name string. since we really do want to catch name changes that don't change the content we will have to think harder here. maybe up to a certain name length we just store the whole name in-place along with the hash value. the point is to get a standard-size hash value we can cast into an integer
- we use modular exponentation (i.e. diffie-hellman) to commutatively hash the directory entries
that's it!
it should be possible to store the resulting hash tree in a fixed amount of space per directory entry, and you can limit the size of the transmitted hash tree by just stopping your bread-first search after some point
then you get a certificate that not only indexes into a remote object db, it's also self-certifying
@realn2s @heptapodEnthusiast this comes from the other thing i really wanted, which was to avoid having to recompute the whole hash tree upon change. so you can have a hash tree all the time with (hopefully) much less performance impact
Snixstoresnixstoresnix
@nobody they haven't made it into a filesystem or tried to go for kernel support at all which is ridiculous if you genuinely want ironclad semantics. the nix store also necessarily implies a global filesystem view which is terrible to optimize and it's also a failure of isolation. the reason making this faster might be useful is because every single process on the system is going to be bound to a named "domain" which is a managed filesystem view that can only share content across domains with a process that has access to both
@nobody i promise i'm not trying to hate on you personally here but it's incredibly annoying to me when nixers (it's specifically nix users) act like sandboxing is this sort of all-or-nothing trust relationship when sandboxing a process execution is basically the easiest part because you just use the OS tooling for that.
pants (i.e. me) had considered a FUSE fs for at least 5 years running but:
- FUSE is annoying to ship and very nonportable
- it still wouldn't let us manage IPC or task scheduling at all
- it absolutely doesn't give us persistence guarantees
the one thing it does do is let us virtualize i/o. but i think that's much better done by reaching into the guts of the compilers themselves and making them do i/o through my library
@nobody and if you have a fork of the compiler (but specifically one that does not change code gen in any way at all) then you (meaning me, who is doing an insane build tool that is not pants) can probably handle most of the other functions too
@nobody being a build tool or a package manager makes things a lot easier. build xor pkg is the motto
@hipsterelectron @nobody portage is crying in the corner
@hipsterelectron DH and RSA are the canonical examples of vulnerable to factoring or discrete logarithm breakthroughs and surprise, that's exactly what Shor's algorithm does.
