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!"
Why would you name an algorithm after what appears to be a support email address?
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...
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).
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!
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.
less than 100 lines of code!
Fewer.
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.
Support for ED25519 keys and Curve25519 key exchange is also welcome. Along with the ChaCha cipher and Poly1305 MAC, they are all excellent crypto primitives.
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.
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!
Yeah, as another commenter said, I don't care if the "grandfather" algorithm Salsa was a finalist in eSTREAM, since this guy has touched it, I'll be adding it to my disabled ciphers list for my openssh server unless/until someone like Bruce Schneier says it looks good.
Anyone can come up with a cipher that encrypts and decrypts data, but is it really secure or does it suffer from fatal flaws?
The algorithm is virtually identical, with a minor tweak of the matrix and round function to improve diffusion and map better onto SIMD operations.
The algorithm is fundamentally identical to salsa, just rearranged a bit. It is so simple, that it doesn't take a cryptographer to see there is little room for deception here. It would be glaringly obvious to anyone skilled in the art.
> 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.
Did he design torque then? They seem to love /var/spool/
from DJ Jazzy Jeff.
...DJ Bernstein, drop me a funky fresh cipher. umph umph
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.
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.
This is why I translate plaintext into Pig Latin and then apply a Caesar Cypher. Ha! The NSA will never figure that one out!
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?
He's ten times as smart as the average brogrammer, in fact
FTFY.
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.
> 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".