> Designed to be as secure as a one-time pad, without a weakness due to the use of repeating keys,
That immediately shows that the person writing it doesn't know cryptography. You simply can't get the security of one-time pad without having a key the size of the data, and if you do, just use it as the pad.
> Crystalline employs information loss as the basis of its security.
If encryption loses information, there’s no way decryption can bring it back.
In the extreme
def encrypt(s):
return “(TOP SECRET)”
def decrypt("(TOP SECRET)"):
return sa. The author cannot decrypt it either, unless he's cheating somehow, or
b. It's not really losing information and the author is lying.
> That immediately shows that the person writing it doesn't know cryptography. You simply can't get the security of one-time pad [..]
Talking about a one-time pad at all in the context of making something actually secure for internet usage, shows that the talker doesn't know about cryptography.
A one-time pad having "perfect security" is only true in the context of a particular security model that doesn't generally hold true on the internet - one where the adversary cannot change the ciphertext whilst it is in transit.
Under a more realistic security model, we need a message authentication code or some other equivalent, to protect against adversaries changing the ciphertext. It's a well-known theorem of modern cryptography that in fact if you don't have secure authentication under this model, then you cannot achieve secure privacy. In other words, your ciphertext has to be bigger than the plaintext for security on the internet.
(There is in fact a one-time-pad equivalent for MACs where your key is the length of the plaintext and the ciphertext ends up being several multiple times the length of the plaintext, but crackpots when making security arguments about "one-time pads" generally aren't referring to this and aren't even aware of the existence of this. It's a relatively unknown construction and nobody really talks about it in the context of serious modern cryptography.)
However, this meant there where leftover bits of each key. Though if you think of each bit as a different key then sure, just start each message with the offset.
The idea of a one-time-pad is that you're basically just randomly flipping the bits of your input, which means the output of an OTP cipher is indistinguishable from random data.
If you're using the same key multiple times though, then the output of the cipher (considered over time) won't be random, and you'll be able to detect patterns from the original input in the cipher output (e.g., the shape of an image, frequency of certain letters).
The thing is, if you know the same key has been used a second time, then yes, having both outputs (can? will? must? could?) helps to acquire the key.
But how do you know they're using the same one? Or how are you sure, they're not? All you have, are two pieces of random data.
The output of any _one_ use of the pad is, yes, but the point is to consider all of the data that an attacker may have. If you re-use the key multiple times, then the entirety of the cipher texts an attacker has is not random. (See also: https://xkcd.com/221/)
> But how do you know they're using the same one? Or how are you sure, they're not?
You'll be able to tell because you'll see patterns in the data: https://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb....
You encrypt the data ABCD -> EDGF.
You encrypt the data DEFG -> HGJI
Someone intercepts the data, and has: EDGF and HGJI
And now?
Or maybe like this: Since OTP and data are interchangeable, due to matching lengths, isn't using the same OTP with different data, essentially the same like using the same data with a different key?
Story time: The USSR once reused an OTP key (after years or even decades, can't recall), but a US' three letter agency had the old ciphertext (A') and reused that to break the new ciphertext (B'). They probably had some scheme with a broadcaster saying "use codebook 1234, the secret is GARBLED DATA". At least that's the story a cryptography lecturer told us (and the fragments I remember).
I guess one thing to note is that, if what you were transmitting was just random noise to begin with, OTP re-use may not matter/be evident. But essentially all data that people care about transmitting isn't random noise, it has some structure, and that structure comes through with OTP re-use (more and more the more you re-use and the more data you re-use with).
AIUI, the Enigma machine (not quite an OTP but I think similar) was broken in part because of just a few key re-uses https://en.wikipedia.org/wiki/Cryptanalysis_of_the_Enigma#Op...
From my limited knowledge of the matter, that alone doesn't give you the cypher - you'll need to know additional information about the messages to get the cypher (statistics of words, conditional probabilities of letter sequences etc.). But without the one reuse of your cypher, you couldn't apply these techniques.
That ASCII example is rather extreme, but all messages have patterns as long as you’re given enough of them you can break a reused OTP.
Here's a good illustration of the principle: https://crypto.stackexchange.com/questions/59/taking-advanta...
Obviously it's more complicated with text (where you have less information filled in); for that you have to do crib dragging which is a bit more involved but not fundamentally difficult.
I've always assumed it was just adding the key-value to the data-value, as is described in the Wikipedia article[0].
And those two can't be the same, e.g. with both data and key value 'a' (0x5c), I'd get 0x0 with XOR and 0xb8 with addition.
EDIT: Ah, damnit, second paragraph, it says: "On July 22, 1919, U.S. Patent 1,310,719 was issued to Gilbert Vernam for the XOR operation used for the encryption of a one-time pad."
Everything I've posted in this thread about OTP was under the assumption of an additive cipher. My bad.
Edit for your edit: All of this discussion applies the same for additive OTP as it does for XOR OTP; once you have depths you can start applying the OTP (however it's done) “in reverse” as it were to begin extracting patterns in the data.
You can easily discover reused keys if you can guess any part of either plaintext. From that guessed fragment, you can recover both plaintexts and the entire key (pad) using the "Zig Zag" method.
(P=plaintext, C=cyphertext, K=reused_pad, ⊕=XOR)
If we capture two ciphertexts that reused the same key
C1 = P1 ⊕ K
C2 = P2 ⊕ K
D = C1 ⊕ C2 = P1 ⊕ P2
Professor Brailsford's explanation[1] of the method on Computerphile is nice introduction to this type of cryptanalysis.
In 09:05 ([0]) you can see why, namely that K and K cancel each other out.
I don't think this would be the case with an additive cipher.
EDIT: Continuing the thought with an additive cipher:
P1 + P2 = C1 + C2 + 2K
2K = P1 + P2 - (C1 + C2)
K = P1/2 + P2/2 - C1/2 - C2/2
C1 = P1 + K
C2 = P2 + K
C1 - C2 = P1 - P2
P1 + P2 = C1 + C2 - 2K
2K = C1 + C2 - (P1 + P2)
It does not appear he's uploaded slides yet but here is link to session: https://bsidessf2020.sched.com/event/Ybgu/break-crypto-like-...
He said he was going to check in his code to GitHub so may be able to find same with some detective work.
Essentially you could xor two encrypted images with the same OTP and see them sort of superimposed on one another.
Depends how motivated your enemy is
Would like to know, if my assessment on additive OTP is correct, if anyone knows?
EDIT: I mean, of course you still shouldn't, but where the XOR catastrophically fails after just a single reuse, the additive one should be more robust, even with reuse. The Venona Decrypts were additive-OTP, I postulate, the decryption rate would've probably been higher with XOR-OTP.
Like if ciphertext is "supersecret" then it feels like plaintext can't be more obvious and OTP must be "00000000000", but there's nothing anywhere to logically/mathematically support it. OTP could be something else and plaintext could be "hackernews" or "ycombinato".
In reality a simple XOR with a random sequence preserve enough entropy of data that I've heard you could make out voices if used on media, so payloads must be scrambled, but that's not recovery, only a guess. ANY reuse breaks that notion and make it not an OTP cryptography.
— Bruce Schneier
https://www.schneier.com/blog/archives/2011/04/schneiers_law...
Everyone peed on him and he never came back.
The poor sap was right though. The proven algorithms tend to fail catastrophically when used or implemented incorrectly.
I'm fascinated by his gentle nature as an algorithmic thinker who applied computer science to all aspects of his experience
To people like this, arguing is like punching. If you punch someone and they get up, they're a "tough opponent". That doesn't mean that punching is ineffective on other people. They just don't understand at their core that once an argument is shown to be false, it can never be reused. Their mind just doesn't work this way. They think "Well, left-hook didn't work on this guy, but maybe it'll work in that guy" or "This guy didn't fall for this argument, but maybe that guy will."
It's deeply dishonest, but I'm not convinced they're even aware of this.
So, just from a cursory look at his code, the glaring problems I see are:
1) It'll crash if you feed it more than 256MB because of the way the C# BitArray class works. He's also using 32-bit ints in several places that have similar issues. These are implementation details, but it just goes to show how thoughtless the "reference implementation" is.
2) Similarly, the reference implementation copies the entire data into the BitArrary (and then back into a byte array) for each "round". This is spectacularly inefficient. He never mentions throughput in terms of MB/s/GHz or any such thing. I wonder why...
3) It's not a stream cipher. You need to encrypt the entire file. Again, he could come up with some sort of streaming version by feeding in the last few KB of the previous encrypted chunk into the next chunk, but he hasn't. As the long history of various streaming ciphers have shown, this is actually a hard problem to solve efficiently and securely. This is why AES-GCM is the hot new thing: it's both.
4) If either the key or salt values are all 0s then the encryption does nothing. AES for comparison will still encrypt your data with some level of security even if the IV initialisation is not perfectly random or skipped.
5) He's calculating the offsets as an "int" from a byte multiplied by a byte. Hence the maximum shift is 65536 positions. This is just big enough to exceed L1 data cache on most platforms, but have a high hit ratio. Whether you hit the L1 cache or not depends on the Key & IV values, so this is a recipe for timing-based side-channel attacks. Constant-time cyphers are basically mandatory these days...
6) Related to the above: The bit shifts are only in an 8KB window, but the byte shifts are in an 64KB window. I wonder if there's some interaction here where this might make some keys insecure.
7) Despite this windowing, the default "protocol" wraps around the end of the file to the beginning using a modulo the data.Length, so it can't be used as a streaming cipher. To do so, he'd have to introduce a breaking change.
8) The encryption is defined in terms of bit-by-bit and byte-by-byte long-range operations, so there's basically no hope of ever making this efficient. E.g.: with SIMD or similar many-bytes-at-a-time instruction sets. The "state" that would have to be kept in CPU registers is over 64KB, so this is just never, ever, EVER going to compete with something like AES-NI.
I could go on, but I'm wasting my time. This is wasting everyone's time.
The author clearly has no interest in producing something that is secure and usable. He's just enjoying the arguments. He's even posted some of the feedback on his GitHub, proudly showing off the debates he's felt he's won.
Don't feed this troll.
When someone continues to cargo culting useful fragments of knowledge instead of actually learning how/why those fragments actually work, the cargo cult behavior tends to incorporate increasing levels of magical thinking.
A good example of an extreme form of this are the "sovereign citizens" that try to use their "creative" reinterpretations of legal code and procedure almost as an incantation or spell. The like to read from Black's Law Dictionary as if it was a grimoire.
Not experienced in this field but this seems like a good thing to me. Even just using crypto properly appears to be hard, and this 'do nothing when given 0' trait makes the vulnerability very obvious to a quick basic security examination (or even just looking at it in Wireshark), vs needing an expert to do lengthy analysis and figure out that you subtly fucked up the AES initialization and had been running unsafe code for years.
I'd frame it as that it doesn't matter to them. People who aren't in a feedback reward loop with the reality or with others feel no consequences, need of change or improvement. An engineer like you would generally want things to be correct regardless of outcome, but for general internet idiots or lots of startup self-appointed C-classes, sadly that is often not the case.
I suspect you might be confusing a mistake for a conflict, as described here: https://slatestarcodex.com/2018/01/24/conflict-vs-mistake/
You quite naturally see a discussion of a cipher as an attempt to find the truth, and it barely registers for you that it might not be. They probably see a discussion of their cipher as an attempt to persuade, so they use the most effective argument they can think of at a given time, and it barely registers for them that the discussion could be an unbiased attempt to find the truth.
I prefer to think of people's traits not in simple binary terms, but more in terms of high-dimensional attributes. Think: word2vec.
In practice, I find that people are messy. They have their own interests, and hence there's conflict, but they're also lazy, hence the mistakes. There's plenty of room for several kinds of suboptimal behaviour in their squishy meat brains.
Sometimes I feel like I'm The Man From Earth, watching this craziness unfold from the outside.
PS: Watch it, it's a good movie.
So for example, imagine a primitive tribe of humans facing a drought. If they spend too much time discussing options democratically, if they don't all agree, or if they waste time by changing their mind half-way to a source of water, they'll all die. But if they follow an authoritative leader -- even if makes bad arguments or none at all -- they might all make it to the mountain spring in the distance and survive.
The gist of this is that in times of hardship, authoritarian, conservative, or "right-wing" styles of though/argument/politics/whatever can win the day. But in times of relatively low stress, more democractic/left-wing/progressive attitudes can help the tribe discover even more resources than they would have if they always followed the same instructions to go to the same sources. Innovation and exploration can turn the merely adequate into a bountiful plenty, resulting in more healthy babies, etc...
So these attitudes and personality traits are important to have present in the gene pool to make the species as a whole robust against a wide range of challenges and threats.
If you include the fragile egos of sysadmins and executives who refuse to fix their systems, then yes, absolutely.
As for the elitist arrogance, whilst I'm sure these exist in other security-related interactions across the world, the interaction that's the subject of this thread involves plenty of polite comments that
- point out author's lack of background knowledge - refer to short-cut theorems that help evaluate a cipher, implying the author should learn about these theorems - explicitly tell the author to learn about these theorems
In response to this, the very first reply the author gives is "It almost sounds like you have had your soul crushed by bureaucracy over the years and have lost all passion for this field. I hope that's not true."
Yeah, however much "arrogant" you interpret the security people in this thread to be, it's only fair to interpret the OP (Mark McCarron) to be 2-3x as arrogant.
At the end of the day for me, it mostly boils down to some ulterior agenda which seeks to keep competition or perceived threats to the incumbents' control at bay.
Does the NSA have a vested interest in most technology workers being able to competently roll their own encryption schemes? From my very jaded political perspective, I would say absolutely not. It arguably makes their mission exponentially harder if they have to deal with novel approaches to securing communications. They would probably prefer everyone just use ECC with their hand-selected curve parameters.
NSA and GCHQ would absolutely love it if people used novel approaches to cryptography and started kludging together dumb crypto systems. This makes their stated mission considerably easier.
Unfortunately I find that this is all too common.
See also: https://github.com/mmcc1/crystalline http://maldr0id.blogspot.com/2015/05/crystalline-cipher-and-...
The authors inability to take any criticism is stunning, sometimes I wonder if a fragile ego isn't one of the greatest barriers to cyber security..