Forgot your password?
typodupeerror
Encryption Communications Open Source

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

Posted by Unknown Lamer
from the cha-cha-cha dept.
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!"
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by Guspaz (556486) on Wednesday December 11, 2013 @12:59PM (#45661841)

    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)

      by Anonymous Coward

      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.

      • by Etcetera (14711)

        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.

        • by Anonymous Coward

          Qmail is a PITA to set up, andconfigure, and generally understand... but when tuned and customized properly it's incredibly efficient. Even more efficient if you're on underpowered hardware.

          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

    • by c0lo (1497653)

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

      • by lgw (121541) on Wednesday December 11, 2013 @01:52PM (#45662507) Journal

        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?

        • by icebike (68054)

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

        • Damien Miller wrote this implementation, not DJB. DJB designed the ciphers and wrote the reference implementations. DJM and DJB are two different people.
          • by lgw (121541)

            Ah, well, that explains the missing rant then. :)

          • by Dahamma (304068)

            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.

      • by Anonymous Coward

        I can see two bugs in it straight away.

        Has this stuff been audited by a professional cryptographer?

      • by bunratty (545641)
        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!
      • by NekoXP (67564)

        And the other ~150 [bxr.su]

    • by hawguy (1600213) on Wednesday December 11, 2013 @01:51PM (#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

    • by punman (412350) on Wednesday December 11, 2013 @01:53PM (#45662519) Journal

      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.

      • by Z00L00K (682162)

        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.

      • by complete loony (663508) <Jeremy,Lakeman&gmail,com> on Thursday December 12, 2013 @04:37AM (#45668753)
        It's a stream cipher, the tcp sequence number tells you the byte offset in the session's psudo-random bit stream to xor against. Remember that TCP packets could arrive in any order, and multiple small packets might be aggregated when they are retransmitted.
        • by punman (412350)

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

  • by Anonymous Coward on Wednesday December 11, 2013 @01:02PM (#45661873)
  • Guess I'll never know what it looks like.
    • 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

  • by Anonymous Coward

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

  • by fishnuts (414425) <fishnuts@arpa.org> on Wednesday December 11, 2013 @01:07PM (#45661937) Homepage

    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.

    • by Njovich (553857)

      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)

      • */bin is normally read-only but /var is not, and/or it prevents you from setting /var to no-execute?
      • by Anonymous Coward on Wednesday December 11, 2013 @01:29PM (#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.

      • by Anonymous Coward

        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.

      • by Aighearach (97333) on Wednesday December 11, 2013 @01:46PM (#45662421) Homepage

        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.

        • by DarkOx (621550)

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

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

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

      • by TheCarp (96830)

        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

      • by GuB-42 (2483988)

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

    • by psmears (629712) on Wednesday December 11, 2013 @01:42PM (#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.

    • by Gothmolly (148874)

      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 ?

      • by tqk (413719)

        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/

        • by Gothmolly (148874)

          Citing the existence of a directory /var/cache/apt/archive does not demonstrate that it's a separate filesystem.

          Therefore, you fail.

          • by tqk (413719)

            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

    • Actually, he now insists that you should not install it as a separate library, but should include the code with your own programme — http://cr.yp.to/mac.html [cr.yp.to]:

      My fast poly1305aes library is in the public domain. You can and should include it in your own programs, rather than going to the effort of linking to a shared library; the compiled code is between 6 and 10 kilobytes, depending on the CPU.

      Of course, it being in the public domain, this is merely a suggestion, and, as a developer, one could basic

  • by fisted (2295862)
    --- 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_c
  • by flyingfsck (986395) on Wednesday December 11, 2013 @01:10PM (#45661985)
    This is great news.
  • What about HPN? (Score:4, Insightful)

    by Vesvvi (1501135) on Wednesday December 11, 2013 @01:33PM (#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.
  • less than 100 lines of code!

    Fewer.

    • Unfortunately, the actual correction should be "more."

      • 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.
  • by Anonymous Coward

    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

    • by Virtucon (127420)

      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]

    • Wouldn't running a block cipher like AES or a hash function like SHA-3 in counter mode produce a suitable stream cipher?
  • 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 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.

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

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

        • by Anonymous Coward

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

        • by amorsen (7485)

          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

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

            • by amorsen (7485)

              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.

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

                • by amorsen (7485)

                  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.

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

      • 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]

    • by Burz (138833)

      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?

Programmers do it bit by bit.

Working...