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
16
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.
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.
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 take a look at International Standard Content Code (ISCC)
https://www.iso.org/standard/77899.html
@lavaeolus @realn2s i am terribly fascinated about the ISO standard even thought it seems i cannot at all get a hold of it. i have a few concerns with some statements on this blog.tib.eu post however:
- it is EXTREMELY strange to be mentioning MD5 as if it were an "exact cryptographic hash", in 2024 of all years:> (We have been using a similar MD5 checksum in the details of objects for decades, e.g. in many media or document repositories).
there is no discussion nor mention nor link to discussion about what constitutes a cryptographically secure hash function. MD5 has been known to be broken against second preimage attacks for at least two decades. it was also designed by ronald rivest who seems to only make US government backdoors and nothing else.
i normally would not emphasize this this much, i just feel it is so shockingly negligent to write that it was worth noting. SHA-256/SHA-512 should be widely available and are fine even if i like different ones. the issues with merkle-damgård constructions like SHA-1 and SHA-256/512 are mostly a problem if you're signing data or keeping some other thing secret.
@lavaeolus @realn2s i generally have a huge set of issues with fuzzy hashing (the same issues i have with compression) and don't believe it can be done without a domain expert who can dictate the data layout of a file and describe the structure of it mathematically so that you can even identify the data ranges to calculate the patch against.
because really even my very length mechanism here with storing the whole checksum tree is just about calculating a diff at the end of the day. so this blog post seems extremely credulous of
This type of application is not new, research has been going on for decades – the only thing that is new and important for our context is that a workable specification has been agreed internationally as a standard for an identifier.
i think it is possible to define a specification for this to some degree (it would allow me to calculate a minimum patch for my version control / filesystem idea). so maybe they've done just that. but i get very antsy about the idea that "oh, it's been stuck in research, now it's ready for us". if people get too comfortable with the slop hash and then use MD5 for the "cryptographic" hash that would be a major cause for concern
@lavaeolus @realn2s yeah this page they linked is more clear https://web.iscc.io/
Create experimental ML-based Semantic Code (images and text only).
slop hashing
Per-chunk fingerprints of text — enables matching fragments inside a document.
this is actually what i want to do for my filesystem / version control tool, so that's totally good. but idk why it's disabled by default
@lavaeolus @realn2s this part deeply confuses me
ISCC is a pure object identifier that is not intended for resolving, i.e. accessing, the object in question.
it is absolutely not widely understood, but a cryptographic signature is generally the same thing as a checksum, and generally it just computes a checksum then does something else to the result. so it's just very strange that they're asserting that the identifier for integrity cannot be used to resolve. i don't understand why
@lavaeolus @realn2s cynically, i would say it's because anyone can create an integrity identifier, whereas DOI registration is highly centralized. wonder what @jonny thinks about the above, goodness knows i'm not even an expert on cryptography
i do absolutely think it would be possible to develop non-slop ontologies of major data formats so that we could get really meaningful diff calculations. that's something a bunch of motivated people could totally do (i was thinking of making it a feature in my version control tool that could be implemented oni a per-repo basis). so i am 100% about the idea of hashing that conforms to document structure, and i think it's totally never been done before afaict
@lavaeolus @realn2s @jonny ohhhhh yeah so
The strength of the ISCC in the context of scholarly publishing and cultural heritage lies not least in its ability to automatically identify a definable work retrospectively.
this is major major surveillance vibes. and that's absolutely one thing hashing can be used for
Proprietary similarity hashes, such as those used for many years by database providers such as Google Scholar,
with full disrespect this is absolute fucking bullshit. they're using fucking n-grams everyone uses fucking n-grams. the only "proprietary" part about it is all the servers google owns. great paper from the literal NSA on n-grams https://dl.acm.org/doi/10.1145/256163.256168
For example, machine learning models could use these ISCC codes to register their training data, thereby achieving a higher level of trust and reliability.
this is very very specifically saying "running their training data through the machine we may or may not be using for surveillance". it is not something the machine learning model would want at all (it would identify copyrighted/illegal content, for example). so maybe the people who advocated for MD5 are exceptionally clueless or maybe they are hungry for hashes. they do seem extremely jealous of google and that's not a good sign
@lavaeolus @realn2s @jonny https://github.com/iscc/iscc-sct this is unfortunately just impossible to use in a non-evil way
One of the most interesting aspects of the Semantic Text-Code is its ability to generate (near)-identical codes for translations or paraphrased versions of the same text. This means that the same content, expressed in different languages, can be identified and linked, opening up new possibilities for cross-lingual content identification and similarity detection.
it's a surprisingly interesting concept and i think hamming distance might be the right choice if you expect your quick-n-dirty translation lookup tables to be wrong for anything not obvious? if they generate a range of possible translations per word that would be pretty evil. not going to think about this more but. my mind is very much made up
also MD5 having more hash collisions but being faster is actually a good quality for surveillance and not integrity imho. but the main benefit for surveillance is just being faster so you can focus on all your other surveillance checksums more easily