Teensy weensy crypto
blog.goeswhere.com
blog.goeswhere.com
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.
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.
That was the point where I went to go write an HN comment, before seeing that Sean had already written it.
Is RC4 secure? No.
> > 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'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.
1. a one-way hash function; 2. a block cipher; or 3. a secure random number generator;
then you have the other two.
So replace "RC4" with Keccak and the argument stands. Keccak doesn't fit in a tweet but it prints onto a single page, which is easy enough to distribute: https://github.com/gvanas/KeccakCodePackage/blob/master/Stan...
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.
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
http://www.cypherspace.org/rsa/
A lot of comments here are talking about how the author is mistaken about the security of RC4.
The point of this post, and the t-shirt, is that it's dumb on many, many levels to ban cryptography.
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.
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 was known to not have this "head room" for a while, and now is largely broken.
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.
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.
Speck's pretty nice and tiny, but who knows if it's backdoored or not :)
Sort of like making a fire is trivial, and it's illegal to do so in many places.
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.
We see it that way, they don't. We certainly won't win this battle by trying to teach them information theory (good luck! :) )
Whether this little technical demonstration does that or not... well, we'll see. But I absolutely can't fault the effort.
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.
It's what Prof. Dave Touretzky did in the case of DeCSS, which got shrunk down to 434 bytes when implemented in C: https://www.cs.cmu.edu/~dst/DeCSS/Gallery/
In legal terms: all you are doing is irrelevant technical wanking.
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.
It's not like the sort of logical reasoning that happens when software engineers battle for the Right way to do something. :)
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.
You just massively increased bandwidth cost and download times.
The noise, which is added to everything, is not compressible so now everything takes a lot more badwidth.
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.
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.
https://web.archive.org/web/20121029045140/http://marutukku....
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.
Just wanted to make sure we're talking about the same thing, counselor. :)
Which is absurd. I thought we hashed this out when DeCSS was a thing.
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.
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.
The Snooper's Charter exists just to keep uppity citizens and low-rent drug dealers under control.
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:
"It shall be unlawful for any person to manufacture for distribution, distribute, or import encryption products intended for sale or use in the United States..." http://thomas.loc.gov/cgi-bin/cpquery/T?&report=hr108p4&dbna...