> With this (and your computer) you can secure a message with a password in a way that's unbreakable. I can't break it, your government can't break it, other people's governments can't break it. Secure.
Argh. No.
> Should you use it? No. There's many important missing features that are present in proper symmetric encryption tools, such as proper key derivation, protection against modification, IVs, and fewer bugs.
This (buried) warning makes these things sound like bells and whistles. The truth is they're essential to security.
Here are some good reasons not to use this for anything:
1. It conflates passwords with keys. Users will not choose high-entropy passwords when left to their own devices.
2. It doesn't take an IV. This means a given password will always generate the same key stream, which means password reuse will lead to plaintext recovery by simple statistical methods. There are no warnings about this.
3. It's not authenticated. An attacker can modify messages in flight with unexpected consequences that very often include plaintext recovery.
4. RC4 is irreparably broken. Dropping 1024 bytes from the key stream might help in the author's intended use-case (assuming users adhere to it), but this is not an effective mitigation in general. The best attacks on RC4 rely on periodic biases that persist over the entire key stream.
Right, but the goal isn't to make a strong or useful encryption tool. The goal is to show that cryptography is, at it's core, rather simple. It's simple enough that we can cram "real" symmetric encryption into the size of a tweet.
It's like building an electric motor out of some scrap wire and some fridge magnets - the motor isn't really useful for anything, but it teaches the basic idea in a way that anybody can appreciate. A useful motor would have bearings, a commutator, multiple windings, an iron core, etc., but adding all that stuff just obscures the basics. Criticizing a school-kid's motor for being weak and inefficient is completely missing the point.
This program isn't supposed to be useful. It's supposed to prove a point.
> but the goal isn't to make a strong or useful encryption tool
> > With this (and your computer) you can secure a message with a password in a way that's unbreakable. I can't break it, your government can't break it, other people's governments can't break it. Secure.
Some governments execute their citizens. If a crypto tool is neither strong nor useful it probably shouldn't be described as such.
You consider a qualification four paragraphs into an article “buried”? Christ. I know attentions spans are short these days, but that's pretty pathetic.
You're acting like the author proposed this as a serious encryption tool, but no sane person could read this article and reach that conclusion. You're only feigning to believe it in order in order to have an excuse to show off your supposedly superior knowledge of encryption.
You are talking about "users" a lot, I doubt the author actually tried to suggest that this was used in some kind of "product" rather that if a encryption can be spread via tweet it makes no difference how you try to ban it's usage, the bad actors ARE going to be able to encrypt their messages, you are just banning honest citizens usage.
Potential bannable use-case for this "bad crypto" is some criminal organization messaging each other and if they are smart enough to use this they can also come up with good password which makes the banning again completely irrelevant and the kicker is that criminals aren't going to use this "bad crypto" they are going to use something even stronger
Without an IV, it's laughably easy to reconstruct the plaintext from multiple messages with the same key. Probably as few as a handful.
That being said, I agree with the other people -- this isn't a "real" thing. It's just something to show how ill-conceived a plan to "ban encryption" is.
It looks like this is the next step in the British tech community's long road of denial to hell: smug overconfidence tightly coupled with plain ignorance.
The blog post makes an absolute fundamental mistake about security in cryptography, and even when corrected you trivialise the correction! Let me make it absolutely clear: the blog post author has no idea what he is talking about and his words disqualify themselves.
"Is RC4 secure? For this use-case, yes."
This is absolutely not an even faintly correct statement to make. NO IT IS NOT SECURE. When a cipher is developed, there is some belief on the cost of attacking it. As time goes on we gain more knowledge about it, and the believed cost for RC4 today is pretty much trivial. "Cost" refers to the cost of an attack, not the cost of research. What, you think that because the research (that has already been done) was hard, that attacks are hard? Classic naive "[in]security argument" fallacy. Also, what the fuck does it even mean to say "For this use-case" on a public blog???
There are actual formal precise definitions of "security" in crypto. Learn them. If you don't know them, you can't possibly hope to draw the correct conclusions about what cryptography actually is, and what one does with it, and you should not make wildly inaccurate public blog posts that only serve to further confirm the ignorants' own beliefs.
Yes, it is possible to make lives so hard for non-ignorant real cryptographers doing actual research, such that the economy effectively has no strong cryptography. Then you don't need to ban it outright. So dismissing this attempt by the UK government is extremely naive and dangerous.
But hey, this might backfire as good cryptographers leave the UK and head elsewhere, and the UK economy ends up with people that don't know shit about what security means.
Let's say you wanted to implement a more modern, not (yet?) broken algorithm instead of RC4. Are there any which could fit into a similarly small amount of code?
Is RC4 secure? For this use-case, yes. For TLS, most certainly not. Even today there are many plausible attacks against RC4 in the TLS context, but none of them apply to this static-data world.
RC4 is no longer considered secure for most any purpose. There is known bias in the first few bytes of the cipher that can allow for key-recovery with enough messages sent with the same key. In general you want "head room" in your ciphers such that the best attacks today are not just impractical, but wildly impractical, because attacks tend to get better over time.
RC4 was known to not have this "head room" for a while, and now is largely broken.
If you cannot have something continue to produce output though those periodic biases cannot be obtained, To my knowledge you need a quite large amount of output to exploit them.
So for encrypting a single short message, where an attacker is unable to obtain more output, this should be sufficient for such a purpose.
Still, I wouldn't use it at all, there are other micro alternatives like TweetNaCl which offer a far higher degree of security.
> So for encrypting a single short message, where an attacker is unable to obtain more output, this should be sufficient for such a purpose.
This is fairly vacuous as there are tons of really broken cryptosystems for which this is true; futhermore if you are going to only send a single short message with a given key, an OTP could probably be described in 140 characters of English prose and requires no machine to implement.
It's not vacuous, but there is a history of cryptosystems that have tried and failed to sidestep that RC4 weakness by burning off keystream, so it's worth being careful about it.
This isn't about the triviality of implementing rc4, it's about the absurdity of banning information in a general sense.
Information can be copied at zero cost, transmitted instantly over vast distances, and stored permanently and undetectably in the human brain. Information spreads like a virus in a very literal sense - you overhear a scrap of plot and suddenly a whole film is spoiled. Trying to ban information is a futile as trying to arrest people for catching influenza. This isn't like banning campfires, or even like banning firemaking implements, it's like banning the very idea of fire.
I don't agree at all, I would even think that you are missing the point by saying "they don't see it that way". Well, they don't see it that way because they are ignorant. I agree with the author: Finding a way to communicate this, to educate the ignorant (politicians and voters both) is in fact the crucial battle right now.
Whether this little technical demonstration does that or not... well, we'll see. But I absolutely can't fault the effort.
Responding to your edit, "We certainly won't win this battle by trying to teach them information theory (good luck! :) )":
I think your goalposts are shifting here. A simple example that is easy to spread and easy to demonstrate sounds at least plausible. It certainly doesn't sound to me like teaching them information theory, it sounds more like a challenge: "How will your laws prevent me doing this?" Perhaps they'll block Twitter too?
Yes, but demonstrating the practical difficulty in trying to regulate 102-byte sequences that can fit on a T-shirt (or in a tweet) has a utility of its own.
Yeah, the same sorta utility it has to demonstrate that it is possible for anyone to create a fire in any publicly accessible location in London, for instance in some very valuable historic building. (No, I am not advocating you do so.) I'm just making the point that you didn't get my point. They don't care about how feasible or trivial something is as long as they can ban the usage of it.
In legal terms: all you are doing is irrelevant technical wanking.
Wait, you're calling a DeCSS gallery that has been cited (favorably) in multiple legal briefs and sworn testimony in federal district court "irrelevant technical wanking?"
Just wanted to make sure we're talking about the same thing, counselor. :)
I think he understands it's possible to ban it, it just won't work for the cases that matter.
There's a deeper problem with banning encryption of any form (e.g. "strong encryption") that an encrypted file can be made indistinguishable from random data. If the police or any prosecutor will never be able to tell that a chunk of that was strongly encrypted (technically feasible), the law will never work.
And then there's the sheer absurdity of the idea, which the comparison banishing starting fires doesn't capture.
You are also missing the point. The law mostly cares about intent and the prosecutor (or whatever it is called where you live) being able to convince the jury or judge of what they thought happened.
It's not like the sort of logical reasoning that happens when software engineers battle for the Right way to do something. :)
No, I still maintain it can be engineered around. If enough people start random streams between themselves, is the government going to prevent that? Noise actually can be put into anything, it could be images, sound, random.org, whatever.
You can then embed crypto in those streams. When the prosecutors can't even distinguish intent then there's a problem. No third party may ever know someone exchanged encrypted messages.
So again, I'm not saying the law is fundamentally inconsistent or anything, it's just that it's pretty easy to make it unenforceable and undetectable.
In a shit sack world, the inquisition just points out that there is noise in a lot of your messages and you're done, you don't get a chance to wax philosophical about your intent.
In an even worse world, they just insinuate that you might be communicating secretly.
What is noise anyway? I can program a generative model and inverse generative model couple and then you can transmit data as a image that doesn't look "noisy" but has incompressible information (what I referred to as noise), which could be a cryptogram. The model might generate anything, a innocuous conversation, a picture of a house, whatever. For good models the "inquisition" cannot distinguish you from your neighbor in terms of suspicious activity.
This is just RubberHose, with the same flaws. (Increased bandwidth, and "they" don't care if it's noise or cipher text, they'll happily beat you until you give them what they want.)
No, you're misunderstanding my proposal (w.r.t. Generative Models). This is different from deniable encryption (where an eavesdropper will detect you may be encrypting something), this is traffic literally indistinguishable from normal traffic.
It only fails if the government knows a priori you are a criminal and inspects your hardware.
I thought about making a few proof of concept models for this, but I don't think there's real demand for it (and I'm lazy) -- steganography is probably sufficient for what most people use.
See my comment on Generative Models above. In general there are too many degrees of freedom with modern communication channels for concealing data to be an insurmountable challenge, even if you don't have powerful Generative Models.
Keep in mind the law is targeting malicious actors, people that would likely try to use this sort of circumvention even if it isn't mainstream.
> As the UK's politicians continue to fail to understand what "strong cryptography" or "banning" even mean, I thought I would have a look at how simple strong cryptography can be.
Not that I think it's a good idea or believe they have a good understanding of cryptography but: if they are being rational about it, I'm guessing they think making strong cryptography less convenient will lead to less encrypted communications between parties they're interesting in snooping on. In this case, WhatsApp would be a considerably more convenient to use than using DOSBox.
Yes, the UK gov argument is basically "You can keep your PGP, just run Gmail, Facebook, Skype, etc over HTTP - or at least let us automatically remove the HTTPS encryption for anyone we want in real-time".
They want it this way because:
1) many people will indeed slip when using whatever left is there of "strong encryption" afterwards, especially if it's hard to use - that's pretty good for the UK gov.
2) while they may care about terrorists and whatnot, they care at least as much about spying on many of the people who will never use PGP or even Signal, so again this plan is perfect for them in this regard.
In fact, this plan's only purpose is average-citizenry monitoring. Terrorists and child pornographers already have such an understanding of how to use crypto (or how not use electronic communications at all, like Osama staying offline most of the time -- this is also what mafia bosses do, btw) that they will be completely unaffected. If that weren't the case, bombs would be going off every day all over Britain, and they just don't.
The Snooper's Charter exists just to keep uppity citizens and low-rent drug dealers under control.
Wouldn't Solitaire [1] be a better argument (of this vein) against banning encryption? It's reasonably strong and doesn't even require a computer. Much more practically memorized.
This reminds me a little of [edge|base|corner] cases in programming. It's easy to handle normal parameters. But if you're at or beyond the limits of expected parameters, then what? If you ignore [edge|base|corner] cases, you run the risk of enacting a bad law.
So if a government wishes to restrict encryption, does that mean criminalizing only the distribution of commercial products with strong crypto? Or knowing possession of them? How about if you distribute free software? Possess free software? How about distributing an algorithm that's printed out? On a t-shirt? Set to music? In a sonnet? On a blackboard in a math lecture?
A crypto-ban proposal discussed in the U.S. Congress stopped short at targeting possession, but did target "import[ing]," which presumably would include downloading from an offshore site:
I'm unsure why all the ranting against DOSbox - why not just run MS-DOS in a VM? what are you gaining out of using DOSbox, aside from copy-paste support?
Argh. No.
> Should you use it? No. There's many important missing features that are present in proper symmetric encryption tools, such as proper key derivation, protection against modification, IVs, and fewer bugs.
This (buried) warning makes these things sound like bells and whistles. The truth is they're essential to security.
Here are some good reasons not to use this for anything:
1. It conflates passwords with keys. Users will not choose high-entropy passwords when left to their own devices.
2. It doesn't take an IV. This means a given password will always generate the same key stream, which means password reuse will lead to plaintext recovery by simple statistical methods. There are no warnings about this.
3. It's not authenticated. An attacker can modify messages in flight with unexpected consequences that very often include plaintext recovery.
4. RC4 is irreparably broken. Dropping 1024 bytes from the key stream might help in the author's intended use-case (assuming users adhere to it), but this is not an effective mitigation in general. The best attacks on RC4 rely on periodic biases that persist over the entire key stream.