Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

OpenSSH Has a New Cipher — Chacha20-poly1305 — from D.J. Bernstein

Unknown Lamer posted about 10 months ago | from the cha-cha-cha dept.

Encryption 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!"

cancel ×

140 comments

Sorry! There are no comments related to the filter you selected.

lame name (0)

X0563511 (793323) | about 10 months ago | (#45661811)

Why would you name an algorithm after what appears to be a support email address?

Re:lame name (1)

gstoddart (321705) | about 10 months ago | (#45661925)

Really? I get a dance reference, and a reference to polynomials (Cha-cha/Poly).

Re:lame name (1)

X0563511 (793323) | about 10 months ago | (#45662163)

I'm talking about "chacha20-poly1305@openssh.com" rather than the chacha20 or poly1305 parts :)

Re:lame name (5, Informative)

Anonymous Coward | about 10 months ago | (#45662373)

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.

Re:lame name (0)

Anonymous Coward | about 10 months ago | (#45662549)

Because they already HAVE a MAC using an @ symbol so why not a cypher as well?

umac-64@openssh.com

Re:lame name (1)

Virtucon (127420) | about 10 months ago | (#45663843)

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 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...

Re:lame name (1)

X0563511 (793323) | about 10 months ago | (#45664017)

I'm not talking about the 'chacha' part, but rather the '@openssh.com' part.

100 lines is meaningless (4, Insightful)

Guspaz (556486) | about 10 months ago | (#45661841)

The referenced source file has no actual implementation of the encryption in it, so claiming 100 lines is a bit silly...

Re:100 lines is meaningless (1, Interesting)

Anonymous Coward | about 10 months ago | (#45661991)

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:100 lines is meaningless (2)

Etcetera (14711) | about 10 months ago | (#45662475)

For the exact same mail volume on the exact same hardware Postfix runs about a third the load average of qmail.

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.

Re:100 lines is meaningless (0)

Anonymous Coward | about 10 months ago | (#45662805)

I had a similar experience, but you shouldn't take some Anonymous Coward's word for it. Try it for yourself. Or you could just do a Google search and see what turns up.

Re:100 lines is meaningless (0)

SuneSpeg (662034) | about 10 months ago | (#45662523)

Line 74 in source = Clue #1 he isnt a programmer: 74 goto out;

Re:100 lines is meaningless (5, Informative)

Anonymous Coward | about 10 months ago | (#45662637)

That's how you do a try...finally block in C.

Re:100 lines is meaningless (0)

Anonymous Coward | about 10 months ago | (#45663029)

Not to mention he's talking about line 74 in Miller's ssh implementation not DJB's chacha/poly.

Re:100 lines is meaningless (0)

Anonymous Coward | about 10 months ago | (#45663677)

That's what happens when you bring C++ programming practices back to C.

Re:100 lines is meaningless (2)

c0lo (1497653) | about 10 months ago | (#45662085)

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 (4, Funny)

lgw (121541) | about 10 months ago | (#45662507)

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:100 lines is meaningless (1)

icebike (68054) | about 10 months ago | (#45662875)

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:100 lines is meaningless (1)

ebno-10db (1459097) | about 10 months ago | (#45662979)

On Slashdot, literalism knows no bounds.

Re:100 lines is meaningless (0)

Anonymous Coward | about 10 months ago | (#45664163)

I know. When I see someone say "WHOOSH," I wonder if at least one person looks because of how literal some people take things.

Re:100 lines is meaningless (1)

Anonymous Coward | about 10 months ago | (#45662617)

I can see two bugs in it straight away.

Has this stuff been audited by a professional cryptographer?

Re:100 lines is meaningless (1)

bunratty (545641) | about 10 months ago | (#45662873)

I was about to say it had no comments, but then I found this gem:
/* stopping at 2^70 bytes per nonce is user's responsibility */
That'll come in handy as soon as someone wants to encrypt more than 2^70 bytes!

Re:100 lines is meaningless (1)

NekoXP (67564) | about 10 months ago | (#45663899)

And the other ~150 [bxr.su]

Re:100 lines is meaningless (5, Insightful)

hawguy (1600213) | about 10 months ago | (#45662495)

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 (4, Interesting)

punman (412350) | about 10 months ago | (#45662519)

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:100 lines is meaningless (-1, Flamebait)

icebike (68054) | about 10 months ago | (#45662903)

When you don't understand encryption, it all looks like ROT13.
Best leave that to the big boys.

Re:100 lines is meaningless (1)

punman (412350) | about 10 months ago | (#45663111)

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:100 lines is meaningless (0)

Anonymous Coward | about 10 months ago | (#45663425)

You're starting in the wrong place. Go implement RC4 and come back when you understand it. Really, I'm serious. RC4 is a great introduction to the basics of stream ciphers and different sorts of attacks. You can hand-write the code for an implementation on the back of a business card.

Re:100 lines is meaningless (1)

Z00L00K (682162) | about 10 months ago | (#45664157)

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.

Pastebin mirror of code (5, Informative)

Anonymous Coward | about 10 months ago | (#45661873)

Re:Pastebin mirror of code (4, Informative)

damaki (997243) | about 10 months ago | (#45662161)

Wow it's less 100 lines (excluding chacha_ivsetup, chacha_encrypt_bytes AND poly1305_auth). So I guess it's not 100 lines...

Re:Pastebin mirror of code (0)

Anonymous Coward | about 10 months ago | (#45662749)

Look, I can do it in only 1 line of code:

          int chachapoly_call_the_rest_of_the_code( struct chachapoly_ctx *ctx, const u_char *key, u_int keylen )

That IS a very simple algorythm....

nginx doesn't increase soft limits (1)

ConstantineM (965345) | about 10 months ago | (#45662541)

The nginx had a soft limit of 128 file descriptors through daemon: :openfiles-cur=128: in login.conf(5) [mdoc.su] , which it apparently doesn't increase automatically, and which were quickly exhausted for internet stream FDs, as per fstat(1) [mdoc.su] . But it's been resolved at 10:03 PT / 18:03 GMT, and there were no known problems since then.

slashdotted (1)

callmebill (1917294) | about 10 months ago | (#45661891)

Guess I'll never know what it looks like.

Re:slashdotted (1)

ConstantineM (965345) | about 10 months ago | (#45663149)

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 served up very quickly due to mfs and good caching. No other problems to report since then; even the search is still very fast, as it should be.

Recent `fstat | fgrep nginx` runs indicate the highest FD is around 200 now, but it did quickly jump to around 400 right after the 128 limit was lifted (within ten minutes of the story being published).

Not less than 100 lines (2, Informative)

Anonymous Coward | about 10 months ago | (#45661921)

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:Not less than 100 lines (2)

ConstantineM (965345) | about 10 months ago | (#45662643)

Those other files are the libraries, the protocol itself is about 100 lines of commented code.

Re:Not less than 100 lines (1)

K. S. Kyosuke (729550) | about 10 months ago | (#45663257)

Rewrite it in proper Forth, and it will be something like three screens or so. :-)

Does DJB insist that the library ... (3, Insightful)

fishnuts (414425) | about 10 months ago | (#45661937)

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:Does DJB insist that the library ... (2)

Njovich (553857) | about 10 months ago | (#45662131)

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:Does DJB insist that the library ... (1)

mrchaotica (681592) | about 10 months ago | (#45662203)

*/bin is normally read-only but /var is not, and/or it prevents you from setting /var to no-execute?

Re:Does DJB insist that the library ... (5, Informative)

Anonymous Coward | about 10 months ago | (#45662231)

/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:Does DJB insist that the library ... (1)

Anonymous Coward | about 10 months ago | (#45662235)

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 ... (0)

Anonymous Coward | about 10 months ago | (#45662255)

How about mounting /var as noexec?
But these days I guess that during installation everybody clicks the "I'm totally n00b/lazy. Just dump the whole damn thing in a single partition." option.

Re:Does DJB insist that the library ... (5, Informative)

Aighearach (97333) | about 10 months ago | (#45662421)

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:Does DJB insist that the library ... (1)

DarkOx (621550) | about 10 months ago | (#45662719)

Its not uncommon for that very reason to mount /var noexec

Re:Does DJB insist that the library ... (1)

buchner.johannes (1139593) | about 10 months ago | (#45663313)

Why not separate every process from each other one ... it's called SELinux and much finer grained than making partitions

Re:Does DJB insist that the library ... (0)

Anonymous Coward | about 10 months ago | (#45664251)

Defense in depth, my friend. As long as processes are running on the machine, there is always a chance that they could break through protection and do something bad. Noexec is an easy way to prevent execution and doesn't rely on anything else. As an aside, there is another benefit to having separate partitions, a bomb may fill up your /var but won't bring your system to its knees nearly as easily.

Re:Does DJB insist that the library ... (2)

Bacon Bits (926911) | about 10 months ago | (#45664775)

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:Does DJB insist that the library ... (0)

Anonymous Coward | about 10 months ago | (#45664503)

"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."

To be fair, the app probably doesnt even know or care since if everything is under /usr then everything ELSE that was at the root, probably is just a symlink to /usr/$WHATEVER. Which isn't an issue. He's talking about one specific program demanding that it be put under /var/ which is totally asinine. /opt? Maybe, fine. /bin? normal, great. ~/bin? Still fine. but /var? thats just weird

Re:Does DJB insist that the library ... (1)

TheCarp (96830) | about 10 months ago | (#45662545)

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, and that pertains to one specific host. Users must never need to modify files in /var/lib to configure a package's operation."

So it is just the wrong place entirely; and there are at least 3 potential correct places, /usr/(lib|bin), /opt/XXX or debatably /(bin|lib).... however even the last one is likely incorrect as those must be on the root filesystem and thus should only contain files that would be required during the boot process, before other filesystems (like /usr) might be available.

The only reason I could see for wanting this stuff in /var would be if the program ran in a chroot and needed to be able to dynamically load libraries. Even that is likely not the best approach.

Re:Does DJB insist that the library ... (1)

GuB-42 (2483988) | about 10 months ago | (#45662555)

/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.

/usr, /bin, /lib and /etc can be mounted read-only in production. That's the case of Android for example. As a result, it is a much safer place for executables and libraries.

Re:Does DJB insist that the library ... (3, Informative)

psmears (629712) | about 10 months ago | (#45662381)

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:Does DJB insist that the library ... (0)

Anonymous Coward | about 10 months ago | (#45663481)

It's public domain, you can do whatever you want with it.

Re:Does DJB insist that the library ... (1)

Gothmolly (148874) | about 10 months ago | (#45663663)

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:Does DJB insist that the library ... (1)

tqk (413719) | about 10 months ago | (#45664279)

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:Does DJB insist that the library ... (0)

Anonymous Coward | about 10 months ago | (#45664403)

Lol, he made a neckbeard angry! Grrr, neckbeard smash!

FTFT (1)

fisted (2295862) | about 10 months ago | (#45661951)

--- 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;
}

Re:FTFT (0)

Anonymous Coward | about 10 months ago | (#45662077)

So you saw no problems with the IV being the sequence number.....

Seems glaring to me that the IV is predictable.

Re:FTFT (1)

Sun (104778) | about 10 months ago | (#45662173)

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:FTFT (1)

kasperd (592156) | about 10 months ago | (#45663447)

the IV is not considered secret.

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 no sooner than that. SSL was broken due to encrypting data in CBC mode, where the data was not yet known, when the IV was chosen.

Re:FTFT (0)

Anonymous Coward | about 10 months ago | (#45662455)

As long as keys are never re-used it doesn't matter if the IV is predictable or not. This is the same tradeoff as when using block ciphers in counter mode.

Re:FTFT (1)

kasperd (592156) | about 10 months ago | (#45663379)

As long as keys are never re-used it doesn't matter if the IV is predictable or not.

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 for successive blocks. But once you have sent a cipher block, it is no longer unpredictable. And if the adversary can influence the next data block once he has seen the previous cipher block, CBC can be exploited.

This is the same tradeoff as when using block ciphers in counter mode.

It is true that counter mode is one of those modes, that do not require unpredictable IVs. In fact you can just use a counter to generate your IV. But if you do not choose IVs carefully, counter mode is one of the weakest modes, you can choose. If you ever reuse an IV, you have effectively reduced the encryption to a multi-time pad. CBC mode with a constant IV would be more secure than that.

The thing is, that counter mode is actually a stream cipher, which operates by generating a stream of bits, which is XORed with the message. All ciphers constructed in this way are vulnerable, if the IV is reused. That is exactly the problem with WEP.

I have seen at least one published article recommending the use of counter mode for storage encryption. It did not explicitly say you should use the sector number as IV, but it was hinting, that's what you were expected to do. Additionally using sector number as IV has been common practice in storage encryptions. Any storage encryption following that practice would be broken if an adversary was able to get the data which has existed at one logical sector number at two different points in time. Ways that could happen includes:

  • Wear levelling on a flash/SSD medium.
  • Remapped sectors on a harddrive.
  • Access to earlier versions due to slight difference in alignment of write head.
  • Encrypted data stored on an untrusted host or accessed over an untrusted communication path.
  • Adversary with physical access to copy the encrypted media more than once.

Re:FTFT (0)

Anonymous Coward | about 10 months ago | (#45663133)

So you saw no problems with the IV being the sequence number.....

This is a stream cypher which is operated in CTR mode. The keys are randomized per connection. Predictable IV is immaterial and actually a feature of the system.

http://en.wikipedia.org/wiki/ChaCha20#ChaCha_variant [wikipedia.org]

Re:FTFT (0)

Anonymous Coward | about 10 months ago | (#45663471)

Aren't those the type-of calling of sizeof and therefore needs parenthesis?

Re:FTFT (1)

kasperd (592156) | about 10 months ago | (#45663605)

Aren't those the type-of calling of sizeof and therefore needs parenthesis?

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 (4, Funny)

flyingfsck (986395) | about 10 months ago | (#45661985)

This is great news.

What about HPN? (3, Insightful)

Vesvvi (1501135) | about 10 months ago | (#45662277)

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.

Dear Editors (0)

mythosaz (572040) | about 10 months ago | (#45662287)

less than 100 lines of code!

Fewer.

Re:Dear Editors (0)

Anonymous Coward | about 10 months ago | (#45662377)

Eye thawed aye cud knot think fewer of Slashdot editors butt it seams ai Cannes.

Re:Dear Editors (1)

aardvarkjoe (156801) | about 10 months ago | (#45662487)

Unfortunately, the actual correction should be "more."

Re: Dear Editors (1)

bazmonkey (555276) | about 10 months ago | (#45662715)

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.

Re: Dear Editors (0)

Anonymous Coward | about 10 months ago | (#45662953)

I've seen it, it's not that great.

Also support for ED25519 keys... (0)

Anonymous Coward | about 10 months ago | (#45662609)

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.

knowing DJB, I don't trust it (-1, Offtopic)

raymorris (2726007) | about 10 months ago | (#45662623)

Based on my interactions with DJB, I wouldn't trust an algorithm he created. He's a smart guy, but he has one failing which tends to negate that - he thinks he's the ONLY smart person in the world. He's ten times as smart as everyone else, he thinks, and he sets out to prove it by consistently doing exactly what all the experts say you should NOT do. A well known example is that everyone says you shouldn't put executables or config files in /var, so DJB does. He's consistent about that, he ALWAYS does what experts say not to do. So I'm sure in the design of this algorithm he was careful to break as many time-tested principles of security as possible.

Re:knowing DJB, I don't trust it (1)

Anonymous Coward | about 10 months ago | (#45662683)

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:knowing DJB, I don't trust it (1)

Anonymous Coward | about 10 months ago | (#45662815)

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:knowing DJB, I don't trust it (0)

Anonymous Coward | about 10 months ago | (#45663359)

The algorithm is virtually identical [cr.yp.to] , with a minor tweak of the matrix and round function to improve diffusion and map better onto SIMD operations.

Re:knowing DJB, I don't trust it (0)

Anonymous Coward | about 10 months ago | (#45662973)

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.

Re:knowing DJB, I don't trust it (0)

Anonymous Coward | about 10 months ago | (#45663513)

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.

Re:knowing DJB, I don't trust it (0)

Anonymous Coward | about 10 months ago | (#45663913)

Did he design torque then? They seem to love /var/spool/

new stream cipher competition from NIST (1)

Anonymous Coward | about 10 months ago | (#45662745)

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.

Re:new stream cipher competition from NIST (1)

Virtucon (127420) | about 10 months ago | (#45664525)

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]

Hachachachacha! (1)

Culture20 (968837) | about 10 months ago | (#45662963)

Encryption scheme names have always been strange. Blowfish, triple-DES, RC4... Now take this new cipher's name. Please!

Re:Hachachachacha! (1)

maxwell demon (590494) | about 10 months ago | (#45663167)

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! (2)

raymorris (2726007) | about 10 months ago | (#45663563)

> 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.

Re:But NOT des(des(des())). Don't do that! (1)

maxwell demon (590494) | about 10 months ago | (#45663689)

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:But NOT des(des(des())). Don't do that! (0)

Anonymous Coward | about 10 months ago | (#45664393)

Try the following silly exercise, which is meant to be reminiscent of RSA:

Take an array of numbers, A, say 1 to 10000000. Plot the histogram of B=A mod(107*5). Now plot the histogram of C=B mod(257*2). Contrast C to the histogram of A mod (257*2).

That is, iterating modulus concentrates a uniform distribution toward small numbers. This is a contraction of the cipherspace which can't be good.

captcha: "nonsense". lol.

Re:But NOT des(des(des())). Don't do that! (0)

Anonymous Coward | about 10 months ago | (#45664443)

That is, there's a mathematical study of the (relatively) simple patterns which emerge when you iterate a function repeatedly [wikipedia.org] . Since simple patterns are what you want to avoid in a ciphertext, it's probably not a good idea to iterate encryption.

Re:But NOT des(des(des())). Don't do that! (2)

maxwell demon (590494) | about 10 months ago | (#45664735)

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've run a rot13 on it before sending.

Re:But NOT des(des(des())). Don't do that! (1)

maxwell demon (590494) | about 10 months ago | (#45664683)

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:But NOT des(des(des())). Don't do that! (0)

Anonymous Coward | about 10 months ago | (#45664947)

It seems to me you are making the GP's point (with a confusing notation for mod, I might add).

Encryption should map onto extremely large spaces, and so adding multiple remappings shouldn't lead to a "contraction of the cipherspace". Seems to me that multiple different encryptions would be better than any one alone, in all ways except for resource usage and key management, which are reasons enough to not do it.

Re:But NOT des(des(des())). Don't do that! (1)

Anonymous Coward | about 10 months ago | (#45664437)

* 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)

Re:Hachachachacha! (1)

Forever Wondering (2506940) | about 10 months ago | (#45664173)

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:Hachachachacha! (1)

Burz (138833) | about 10 months ago | (#45663511)

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?

Has it ever been tested? (0)

Anonymous Coward | about 10 months ago | (#45663077)

Anyone can come up with a cipher that encrypts and decrypts data, but is it really secure or does it suffer from fatal flaws?

Re:Has it ever been tested? (1)

Virtucon (127420) | about 10 months ago | (#45664641)

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.

I prefer my ciphers (0)

Anonymous Coward | about 10 months ago | (#45664083)

from DJ Jazzy Jeff.

Yo (0)

Anonymous Coward | about 10 months ago | (#45664453)

...DJ Bernstein, drop me a funky fresh cipher. umph umph

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?