OpenSSH Has a New Cipher — Chacha20-poly1305 — from D.J. Bernstein 140
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!"
Re: (Score:2)
Really? I get a dance reference, and a reference to polynomials (Cha-cha/Poly).
Re: (Score:2)
I'm talking about "chacha20-poly1305@openssh.com" rather than the chacha20 or poly1305 parts :)
Re:lame name (Score:5, Informative)
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.
Some people prefer Java naming conventions (Score:2)
If the @ sign burns your eyes, try reading it backwards like a Java package name: com.openssh.foo or org.putty.bar.
Re: (Score:2)
chacha20 is a variant of Salsa20. [cr.yp.to] 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 dea
Re: (Score:2)
I'm not talking about the 'chacha' part, but rather the '@openssh.com' part.
Re: (Score:2)
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.
Re: (Score:2)
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. Cha
100 lines is meaningless (Score:5, Insightful)
The referenced source file has no actual implementation of the encryption in it, so claiming 100 lines is a bit silly...
Re: (Score:1, Interesting)
It's just as well. If you'd ever looked at the qmail source code you'd have realized that DJB is not a programmer. That stuff looks like dog vomit. Neither is it efficient. Six or seven years back I converted a half dozen email systems from qmail to Postfix. For the exact same mail volume on the exact same hardware Postfix runs about a third the load average of qmail.
Re: (Score:3)
Then you were probably doing it wrong.
NB: Qmail is a PITA to set up, and configure, and generally understand... but when tuned and customized properly it's incredibly efficient. Even more efficient if you're on underpowered hardware.
Qmail really is a sendmail replacement! (Score:1)
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 impor
Re:100 lines is meaningless (Score:5, Informative)
That's how you do a try...finally block in C.
Nothing wrong with clear goto code (Score:2)
Re: (Score:2)
I second this - `goto' in C is not the hacky technique kids in QBasic use. If you ever look at the kernel source, you'll find plenty of sane `goto' statements there. It's when you improperly use them than sanity begins to ebb away.
Re: (Score:2)
There is absolutely nothing wrong with goto if used in a way that is procedurally correct and readable. A C compiler effectively compiles conditionals down to a bunch of ASM goto (aka "jump") statements anyway, so if it's MORE readable to use goto in C than if/else gymnastics and repeated code/extra functions, why not?
Re: (Score:2)
you'd be surprised then to learn the Linux kernel has a truckload of it. It's a valid construct with specific application. You can even read Mr. Torvalds' opinion about GOTO statements [archive.org]
Re: (Score:3)
The referenced source file has no actual implementation of the encryption in it, so claiming 100 lines is a bit silly...
Yeap. The rest is in about 200 lines of code [bxr.su].
Re:100 lines is meaningless (Score:5, Funny)
And being DJB, surely some of that 300 lines is comments insulting all his fellow cryptographers, the users, and generally complaining that the world is full of idiots?
Re: (Score:2)
And being DJB, surely some of that 300 lines is comments insulting all his fellow cryptographers, the users, and generally complaining that the world is full of idiots?
Or, you could click the link and find out how wrong you are....
Re: (Score:2)
On Slashdot, literalism knows no bounds.
Re: (Score:3)
Re: (Score:3)
Ah, well, that explains the missing rant then. :)
Re: (Score:2)
No, the code link in the post you replied to is for Chacha itself from DJB, not the DJM code that *used* it (which was linked in the article).
Not only it it free of rants, it's free of ANY useful comments, which IMO for mostly inscrutable crypto code based largely on C macros is worse than ranting.
Re: (Score:1)
I can see two bugs in it straight away.
Has this stuff been audited by a professional cryptographer?
Re: (Score:2)
That'll come in handy as soon as someone wants to encrypt more than 2^70 bytes!
Re: (Score:2)
And the other ~150 [bxr.su]
Re:100 lines is meaningless (Score:5, Insightful)
The referenced source file has no actual implementation of the encryption in it, so claiming 100 lines is a bit silly...
Using their metric of excluding the function calls that do the real work, OpenSSL only needs one line of source code to encrypt a file:
#!/bin/bash
openssl enc -aes-256-cbc -salt -in somefile.txt -out somefile.txt.enc
Re:100 lines is meaningless (Score:4, Interesting)
I read through the implementation presented and the additional ~200 lines of code for each of the authentication (poly1305) and encryption (chacha.c) pieces of this protocol. Coming from the perspective of an experienced coder but relative crypto novice this just looks like a very sophisticated shifting algorithm (like ROT13, on steroids) keyed on the TCP sequence number. Is this considered acceptable security for a data stream? I'm honestly curious, I haven't played around with crypto functions very much.
Re: (Score:2)
A good encryption is beautiful and simple while still completely unpredictable unless you have the right key.
The less code that you have to use to perform the encryption the better.
Re:100 lines is meaningless (Score:4, Insightful)
Re: (Score:1)
...the tcp sequence number tells you the byte offset in the session's psudo-random bit stream to xor against.
Perfect explanation. I get it now. Thanks!
Re: (Score:1)
When you don't understand encryption, it all looks like ROT13.
Best leave that to the big boys.
If you can't explain it, just say so. Thanks anyway though.
Re: (Score:2)
How about 108? https://chromium.googlesource.com/chromium/deps/nss/+/50796110f60d034dfab3d8876f62d715f31aaa9f/nss/lib/freebl/chacha20/chacha20.c [googlesource.com]
Pastebin mirror of code (Score:5, Informative)
http://pastebin.com/3YaRWXFs [pastebin.com]
Re:Pastebin mirror of code (Score:5, Informative)
Re: (Score:2)
nginx doesn't increase soft limits (Score:1)
slashdotted (Score:1)
Re: (Score:1)
The nginx on BXR had a soft FD limit of 128 (:openfiles-cur=128:) through the default login.conf(5) [mdoc.su], which it doesn't seem to increase automatically, and which it was hitting at 17:59 (if not earlier) as per fstat(1) [mdoc.su], and which applies to internet sockets, too, so, during some time between 17:52 and 18:03, when nginx [bxr.su] was manually restarted with the increased soft limit, BXR [bxr.su] was indeed slashdotted!
BTW, this was probably due to the HTTP keep-alive feature, and not the raw number of requests, which are all ser
Not less than 100 lines (Score:2, Informative)
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).
Re: (Score:2)
Re: (Score:2)
Does DJB insist that the library ... (Score:4, Insightful)
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.
Re: (Score:3)
What's so dangerous about having executables and libraries in /var? It seems pretty common practice? (I have no particular like for qmail, but I'm curious why this part is an issue)
Re: (Score:2)
Re:Does DJB insist that the library ... (Score:5, Informative)
/var is meant for variable content. Such as the mail spool and tmp directory. Data on this filesystem often comes from external sources such as email. It is recommended for this file system to be mounted with noexecute flag to reduce the likelihood of a downloaded data to be executed.
Having binaries on /var means that this filesystem can not be mounted with this option and therefor reduces security a bit.
Re: (Score:1)
Because mounting /var as noexec is a reasonable (though possibly not common) security control. Since applications need to write to /var for logs, etc, making /var noexec is a safeguard in case the application gets compromised. If you have to put libraries and executables under /var, that prevents this control from being used.
It also fucks up and goes against every other system of organizing executables & libraries in linux, which makes it stupid on its face.
Re:Does DJB insist that the library ... (Score:5, Informative)
Because on production servers it is common to have var on it's own partition, and that is the filesystem that holds the logs, which an attacker can cause data to be written to. Also it has to be writable by the running services, and allowing services to write and execute new binaries is a step in many attacks. So it is a typical thing a sysadmin wants to do, to prevent executing code there.
That said, the distro I'm using puts the executables under /usr regardless of where the upstream developer wants them to go. That isn't a decision for the app, it is one for the distro.
Re: (Score:2)
Its not uncommon for that very reason to mount /var noexec
Re: (Score:2)
Why not separate every process from each other one ... it's called SELinux and much finer grained than making partitions
Re: (Score:3)
SELinux has a higher administrative burden. Mounting /, /boot, /usr, /usr/share, /usr/local, /var, and /tmp all with 'ro', 'noexec', 'nodev', etc. as appropriate means you prevent many types of attacks and you don't have to write a custom SELinux policy, and maintain it, and debug all the issues. Increased granularity = increased complexity. Options in mount = KISS.
Re: (Score:2)
In addition to the other answers, I will mention the FHS or Filesystem Hierarchy Standard: http://www.pathname.com/fhs/pub/fhs-2.3.html [pathname.com]
Note its descriptions of /bin /usr/bin /var and /var/lib
Particularly:
"/var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files."
and /var/lib:
"This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, a
Re: (Score:2)
/var meant to be both writable and persistent. That makes it very sensitive and a good target for attackers. This is the reason why it is a good idea to avoid putting executable files in there. In fact the less you rely on /var, the better.
Re:Does DJB insist that the library ... (Score:4, Informative)
He's always insisted that his qmail binaries get installed under /var/qmail,
Not true. He used to, but he has since placed qmail in the public domain [cr.yp.to], so you can do whatever you want.
Re: (Score:2)
10+ too late, postfix have since steamroller qmail in all fields
Re: (Score:2)
Caring about what goes in what filesystem is neck-beardy.
Who mounts /var noexec by default? How many people have already dispensed with a separate /var ?
Re: (Score:2)
Caring about what goes in what filesystem is neck-beardy.
Using "neck-beardy" as an epithet is far worse, !@#hole.
How many people have already dispensed with a separate /var ?
You've never run Debian; gotcha. See /var/cache/apt/archives/
Re: (Score:2)
Citing the existence of a directory /var/cache/apt/archive does not demonstrate that it's a separate filesystem.
Therefore, you fail.
Re: (Score:2)
Citing the existence of a directory /var/cache/apt/archive does not demonstrate that it's a separate filesystem.
I was answering his, "How many people have already dispensed with a separate /var ?" Besides, your comment is irrelevant. Lots of stuff *can* be in a separate fs; doesn't mean they either have to, or should be. Lots of people don't see any need for separate filesystems at all, given they've got obscene amounts of free disk space to work with these days.
/var/cache/apt/archive is where the Debian installer dumps debs that it's downloaded prior to installing/upgrading them. I've filled the root fs
Re: (Score:1)
Of course, it being in the public domain, this is merely a suggestion, and, as a developer, one could basic
FTFT (Score:2)
+++ 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_c
Re: (Score:2)
I have not analyzed this cypher, but generally speaking, the IV is not considered secret. In fact, under the common block cyphers, it is considered completely okay to actually publish it.
Shachar
Re: (Score:2)
Of course not. After all, most cipher modes sent the IV directly on the wire. However it is only sent once the data has been encrypted. If the adversary knew the IV before you encrypted the data, the adversary could influence the content of the data based on her knowledge about the IV, and break the encryption that way. If you are using a cipher mode, which requires the IV to be random, then you must choose a random IV after the data to be encrypted has been set in stone, and
Re: (Score:2)
That depends a lot on the mode. CBC mode is vulnerable to plenty of attacks, if the IV is predictable. And what predictability means in this context has taken some people by surprise. If the end of the stream of data is not set in stone once you start encrypting, does that mean the IV is predictable? The way CBC has been used in SSL did have a weakness because of that. The cipher blocks sent across the network are used as IV
Re: (Score:2)
To me even asking that question is indication, that you should include parenthesis. If the author or any of the readers are unsure if parenthesis is required or not, it is better to use parenthesis more often than strictly required. In other words, you can omit the parenthesis only if you know for sure, it will work and that everybody who will read it, also understand the rules.
Thank you Damien (Score:5, Funny)
What about HPN? (Score:4, Insightful)
Dear Editors (Score:1)
less than 100 lines of code!
Fewer.
Re: (Score:2)
Unfortunately, the actual correction should be "more."
Re: Dear Editors (Score:2)
new stream cipher competition from NIST (Score:1)
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 t
Re: (Score:2)
RC-4 is on its last legs, and there's isn't much of a consesus on what to replace it with.
Not to mention patent trolls lurking wanting to sue you if you use TLS with RC4. [arstechnica.com]
Counter mode (Score:2)
Hachachachacha! (Score:2)
Re: (Score:1)
I can't see anything strange about "triple-DES". "triple-DES" is exactly what the name suggsts: three times DES. And DES is just the abbreviation of Data Encryption Standard.
RC4 sounds like an abbreviation as well (probably version 4 of something), but I have no idea of what and am too lazy to look now. Anyway, nothing strange about that one, either.
OTOH, I cannot imagine how "Blowfish" came to its name.
But NOT des(des(des())). Don't do that! (Score:3)
> 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 fo
Re: (Score:1)
While different hashes on top of each other are quite obviously just as good as the weakest, I don't see why this should be the case for encryption.
Re: (Score:1)
You calculated hashes. I said for hashes it is clear.
But the statement for encryption basically states that if I encrypt my text with rot13 (weak encryption) and then send it through ssh (thus applying strong encryption on top of the weak rot13), the ssh data stream (which is now encrypted with two different algorithms) would be no harder to crack than the weaker of the two encryptions (which clearly is rot13). That is what I don't buy.
Re: (Score:2)
Repeated iteration of functions certainly is relevant for the des(des(des())) situation mentioned in the title and the first paragraph of raymorris' post. I didn't question that part. I did question the part where he claimed that layering different types of encryption on top of each other makes the encrytion as weak as the weakest one. It is true for hashes (which I explicitly acknowledged), but I strongly doubt that I have to fear that data I'm sending through an SSH link is highly insecure just because I'
yes, I misspoke. Still, be careful chaining encryp (Score:2)
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.
Re: (Score:1)
* 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.
I was with you up to this point. E(K1, PT) -> CTe1. D(K2, CTe1) -> CTd2 (Something which since it was not decrypted with K1 is definitely not PT). E(K1, CTd2) -> CTe3 (which since PT != CTd2, is definitely not the same as CTe1). Whereas DES E(K1, PT) -> CTe1.
So 3DES((K1,K2,K1), PT) != DES(K1, PT)
yes, the other keying option == DES (Score:4, Interesting)
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.
Re: (Score:3)
Combining two encryption methods using separate keys can never be weaker than the inner encryption. Proof: if the combined method IS weaker, the attacker could just use the outer method as an attack with a small constant complexity on the inner method, which means the inner method is exactly as strong as the combined method (times a small constant). Unfortunately the same does not apply to the outer method, it is possible for a weak inner method to defeat the security of a strong outer method (e.g. if the i
two examples where combined weaker than inner (Score:2)
> 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 no
Re: (Score:2)
The attacker knows the algorithms in use. The attacker can just run F2 himself, it costs only a small constant time. If F2 exposes a flaw in F1, that flaw was already there from the start.
attacker may (Score:2)
> 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 themsel
Re: (Score:2)
The attack has no complexity. All you save the attacker by not running F2 for them is obscurity, the attacker does not have to spend any computational resources, they just have to know F2.
The security of modern cryptosystems is in the key, not in the obscurity of the algorithms or (at least not intentionally) the attacks.
That's fine if no attacks exist (Score:2)
> 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
First sentence missing the word "not" (Score:2)
The first sentence should read "security absolutely DOES rely on there NOT being easy attacks that
are well known - the obscurity of any attack".
Re: (Score:2)
RC4 comes from Ron Rivest [of RSA fame] and stands for either "Rivest Cipher 4" or "Ron's Code 4" http://en.wikipedia.org/wiki/RC4 [wikipedia.org]
Re: (Score:2)
What I want to know is, do the interactive aspects of this new cipher actually resemble two computers doing the cha-cha?
And, is poly begging for a cracker?
Re: (Score:1)
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.
Re: (Score:1)
The "grandparent"? Rule #1 for cryptography and random number generation: improving a well-tested expert algorithm creates a non-well-tested non-expert algorithm.
Re: (Score:3)
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.
Re: (Score:2)
All Cryptography algorithms go through Cryptoanalysis at some point. [wikipedia.org]
Certainly there's already enough documentation out there on all encryption algorithms and mathematically speaking Salsa20/ChaCha20 are extremely strong.
Re: (Score:2)
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 [eu.org] 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).
Pol