Slashdot Mirror
OpenSSH Has a New Cipher — Chacha20-poly1305 — from D.J. Bernstein
First time accepted submitter ConstantineM writes "Inspired by a recent Google initiative to adopt ChaCha20 and Poly1305 for TLS, OpenSSH developer Damien Miller has added a similar protocol to ssh, chacha20-poly1305@openssh.com, which is based on D. J. Bernstein algorithms that are specifically optimised to provide the highest security at the lowest computational cost, and not require any special hardware at doing so. Some further details are in his blog, and at undeadly. The source code of the protocol is remarkably simple — less than 100 lines of code!"
The referenced source file has no actual implementation of the encryption in it, so claiming 100 lines is a bit silly...
http://pastebin.com/3YaRWXFs
Guess I'll never know what it looks like.
What on earth gave the submitter the idea that it was less than 100 lines? That file linked to is the interface, not the actual core implementation. I count 113 lines in that file, and 218-223 lines depending on which version of DJB's chacha-merged.c you look at (incorporated as chacha_private.h, several versions, several subdirectories).
Really? I get a dance reference, and a reference to polynomials (Cha-cha/Poly).
Lost at C:>. Found at C.
Does DJB insist that his crypto library gets installed under /var/lib? He's always insisted that his qmail binaries get installed under /var/qmail, and had everyone I know in the unix admin/engineering field shaking their heads, knowing that having executables and libraries on the /var filesystem is retarded and dangerous.
--- cipher-chachapoly.c 2013-11-21 03:50:00.000000000 +0100
+++ cipher-chachapoly.2.c 2013-12-11 14:07:54.000000000 +0100
@@ -57,11 +57,11 @@
* Run ChaCha20 once to generate the Poly1305 key. The IV is the
* packet sequence number.
*/
- bzero(poly_key, sizeof(poly_key));
+ bzero(poly_key, sizeof poly_key);
put_u64(seqbuf, seqnr);
chacha_ivsetup(&ctx->main_ctx, seqbuf, NULL);
chacha_encrypt_bytes(&ctx->main_ctx,
- poly_key, poly_key, sizeof(poly_key));
+ poly_key, poly_key, sizeof poly_key);
/* Set Chacha's block counter to 1 */
chacha_ivsetup(&ctx->main_ctx, seqbuf, one);
@@ -89,9 +89,9 @@
r = 0;
out:
- bzero(expected_tag, sizeof(expected_tag));
- bzero(seqbuf, sizeof(seqbuf));
- bzero(poly_key, sizeof(poly_key));
+ bzero(expected_tag, sizeof expected_tag);
+ bzero(seqbuf, sizeof seqbuf);
+ bzero(poly_key, sizeof poly_key);
return r;
}
CLI paste? paste.pr0.tips!
This is great news.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
I'm talking about "chacha20-poly1305@openssh.com" rather than the chacha20 or poly1305 parts :)
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
This is all well and good, but what's the status of seeing HPN-SSH or similar incorporated? FreeBSD has incorporated it, but it's still messy on Linux systems.
SSH extensions are all specified by ASCII names. Standard extensions have names like "shell", "x11", and "port-forward", while vendor-specific extensions use names like "foo@openssh.com" or "bar@putty.org" so there's no naming collision risk.
Unfortunately, the actual correction should be "more."
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
The nginx had a soft limit of 128 file descriptors through daemon: :openfiles-cur=128: in login.conf(5), which it apparently doesn't increase automatically, and which were quickly exhausted for internet stream FDs, as per fstat(1). But it's been resolved at 10:03 PT / 18:03 GMT, and there were no known problems since then.
That's the magic of peer review - you don't have to trust the creator. The grandparent of Chacha, Salsa, was one of the winners of the eSTREAM cipher competition so it has seen plenty of review.
Unfortunately, it's "greater". The code is greater than 100 lines. There are more than 100 lines in it. If you're talking about the lines, there's more. If you're talking about the container itself, it is greater.
Bruce Schneier has been suggesting that NIST call a competition for a new stream cipher like they did with AES and SHA-3. RC-4 is on its last legs, and there's isn't much of a consesus on what to replace it with.
Even if you don't completely trust NIST anymore (after the Snowden documents), at the very least such a competition would concenrate a lot of people's efforts on the problem, and you could look at the final candidate list and have a good number of choices in addition to the final winner.
There were the eSTREAM/NESSIE/CRYPTREC programs, but they don't seem to get as much press as the NIST competition.
The "grandparent"? Rule #1 for cryptography and random number generation: improving a well-tested expert algorithm creates a non-well-tested non-expert algorithm.
Encryption scheme names have always been strange. Blowfish, triple-DES, RC4... Now take this new cipher's name. Please!
> I can't see anything strange about "triple-DES". "triple-DES" is exactly what the name suggests: three times DES.
True for the purpose for which you posted it, but let me take this opportunity to point out something that
some programmers naively think makes encryption more secure. 3DES does not encrypt with DES three times.
So don't do that. Repeating encryption makes it WEAKER, not stronger, unless other sophisticated
stuff is done between the rounds of encryption.
Repeating the SAME encryption allows for a meet in the middle attack, used by rainbow tables.
Layering DIFFERENT types of encryption, or especially hashing, is no more secure than the weakest layer.
That's trivially provable without any math knowledge in the case of hashing.
3DES, in it's recommended form*, uses three different keys and first ENCRYPTS with key1, then DECRYPTS with key2, then ENCRYPTS with key3, so it's not three encryptions, but two rather encrypt, decrypt, encrypt.
* It's legal 3DES to set k1 and k3 the same, which results in exactly the same output as weak old DES, it's just a waste of cycles. It was allowed for backward compatibility.
chacha20 is a variant of Salsa20. There's also XSalsa20 that uses 192 bit IV.
ChaCha20 is great, I've been using it for the past year and with it being proposed for TLS with the IETF, it's very good for all of us. The world is waking up to the NSA bullshit and we're seeing some of these other standards getting some attention, especially away from anything NIST related or US Government standards related. Salsa20 was submitted and was a finalist in the EU encryption standard. I don't think we'll see the death of AES anytime soon but at least this gives us some alternatives. I'm going to wait for the code to stabilize a bit and start turning it on in my Apache configurations...
Harrison's Postulate - "For every action there is an equal and opposite criticism"
I'm not talking about the 'chacha' part, but rather the '@openssh.com' part.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
All Cryptography algorithms go through Cryptoanalysis at some point.
Certainly there's already enough documentation out there on all encryption algorithms and mathematically speaking Salsa20/ChaCha20 are extremely strong.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
Before DES became the practically universal standard, there were multiple very similar algorithms in use, with the most significant difference being the S-boxes. At least one of them turned out to be breakable with 2^2 effort. Even s2des (I would do a superscript 2 but Slashdot is stuck in the 90's) which was specifically designed to be more resistant to differential attacks turned out to be MORE vulnerable to those attacks.
Minor tweaks are worrying.
Finally! A year of moderation! Ready for 2019?
Indeed I misspoke. It's the allowed keying option K1=K2=K3 that's strictly equivalent to DES.
The keying option K1=K3 is slightly more secure than DES.
In the abstract, the main measure of encryption that matters is that it has passed enough scruitiny based on currently known attack techniques. You really have to get your stuff out there before you know how good it is.
To this end, this person isn't a fly-by-night encryption designer, but somone who has a stream cipher accepted into the eSTREAM portfolio. AFAIK, ChaCha is a derivative of the Salsa20 stream cipher and can be used similarly to RC-4 (although the similarities are only superficial to RC-4).
Poly1305 is really a just a MAC (message authentication code) technique which relies on an underlying cipher (usually AES). It's more sophisticated than the standardized CMAC (cipher-based MAC) but more simiilar to GMAC (the galois-field MAC that is part of the GCM encryption technique used by WiGig).
You're right, of course. Unlike hashes (md5, sha, etc), it's possible to chain different encryption without reducing security. Your rot13 & ssh example demonstrates that nicely.
> Combining two encryption methods using separate keys can never be weaker than the inner encryption.
Here are two trivial cases which each prove that false.
F1 is the inner encryption. It's flaw is something like multiplying by some X where X can be zero. Any flaw where one step in the method sometimes nullifies the earlier key-dependant step qualifies. That means that in those cases, some part of the key actually doesn't matter.
F2, the outer algorithm, is inverse of F1.
Thus, in those cases where the non-identical part of the key doesn't effect the output, the following holds:
ciphertext == F2(F1) == 'F1(F1) == plaintext
Obviously ciphertext == plaintext is a little weak.
Another case follows. F1, the inner encryption, is inspired by steganography. C code for F1c, which encrypts one character of the plaintext:
char * f1c(char chr, int key, char * randstr) {
randstr[key] = chr;
return randstr;
}
Oops, sorry I gotta run but I bet you can come up with F2 from there.
If the @ sign burns your eyes, try reading it backwards like a Java package name: com.openssh.foo or org.putty.bar.
Not that there's anything wrong with simulating good C++ practice in C, so long as it's clear. Compare early C++ compilers such as Cfront, which compiled C++ to C.
Wouldn't running a block cipher like AES or a hash function like SHA-3 in counter mode produce a suitable stream cipher?
The world is waking up to the NSA bullshit
. I am sure the NSA approached DJB about this and I am pretty sure the conversation would have been interesting to hear. I bet the NSA guy walked away shrugging his shoulders asking himself what the hell happened.
http://michaelsmith.id.au
So it truly is a sendmail replacement, then; it's got exactly the same pros and cons!
Oh, wait... whenever a sendmail flaw gets discovered it's fixed in about two hours - without having to spend a week arguing with Dan over whether it's actually a flaw or not first.
Let's face it, if ease of configuration and use is important, postfix is the best. If you just want pure power and efficiency, go with sendmail and hurt your brain a lot on the learning curve. Sendmail's got more patched bugs than any other mailserver, so it's honed by evolution, and once you've mastered tuning it (good luck with that) sendmail scales better than anything else.
> If F2 exposes a flaw in F1, that flaw was already there from the start.
Flaws exist. Turning a possible flaw into plaintext counts.
Take for example a leaked database of 10 million encrypted credit card numbers. 99.99% of those look exactly like you'd expect encrypted text to look, random bytes. Of the 10 million, a few look exactly like credit card numbers, because those are the cases with the "multiply by zero" issue.
Yes, without F2, the attacker COULD do their own cryptanalysis and devise F2 themselves, then run it 10 million times. That's harder than not doing cryptanalysis because the developer already ran F2 for them.
Is it ridiculous to think that someone might run what ends up being the inverse of F1? That's almost what 3DES does by design.
Well we need more folks who are willing to push the edges of encryption algorithms and not bow to government pressure. The amount of exposure that the NSA has wrought on all of us, whether it's using TOR or just doing online shopping or banking is enormous and I hope there's some accountability at the end of all of this, I doubt that now but I do have hope. For now I'll just put my faith in algorithms that are strong mathematically and aren't under NIST's hands and have more open, scholarly analysis. ChaCha20 is one of those .
Harrison's Postulate - "For every action there is an equal and opposite criticism"
> The security of modern cryptosystems is in the key, not in the obscurity of the algorithms or (at least not intentionally) the attacks.
Normally, we don't intentionally create attacks, but security absolutely DOES rely on there being easy attacks that
are well known - the obscurity of the attack. If there is an attack (and there's ALWAYS an attack), you're better of not
performing the attack yourself, but forcing the bad guy to first find, then carry out the attack.
An example from the physical world make it crystal clear:
Approximately all locks can be picked. Still, it is _more_ secure to lock your door than to not lock it.
You are arguing that it's just as secure for you to lock it, then pick your own lock and leave it unlocked.
"The bad guy could pick the lock himself", you say. That's true, he could, but requiring the bad guy
to pick the lock before he can get in is more secure than picking it yourself and leaving the door unlocked.
Let's do a select some specific values for your original claim, which was:
> Proof: if [the combined method] IS weaker, the attacker could just [use the outer method as an attack] ...
> on [the inner method], which means [the inner method] is exactly as strong as [the
> combined method]
If [leaving the door unlocked] IS weaker, the attacker could just [pick the lock] ... on the [locked door],
which means that the [locked door] is exactly as strong as [leaving he door unlocked]
The ellipses is where you said "with a small constant complexity". The complexity of F2 is not guaranteed to be constant.
Nor F2 guaranteed to return the plaintext. If it SOMETIMES returns the plaintext, because that timer tick happened
to have a zero as the least significant 32 bits, finding that 1 in 4,294,967,295 for them reduces their burden.
The first sentence should read "security absolutely DOES rely on there NOT being easy attacks that
are well known - the obscurity of any attack".