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

16 of 140 comments (clear)

  1. 100 lines is meaningless by Guspaz · · Score: 4, Insightful

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

    1. Re:100 lines is meaningless by hawguy · · 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

    2. Re:100 lines is meaningless by lgw · · Score: 4, 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?

      --
      Socialism: a lie told by totalitarians and believed by fools.
    3. Re:100 lines is meaningless by punman · · 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.

    4. Re:100 lines is meaningless by Anonymous Coward · · Score: 5, Informative

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

    5. Re:100 lines is meaningless by complete+loony · · Score: 3, Insightful

      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.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
  2. Pastebin mirror of code by Anonymous Coward · · Score: 5, Informative
    1. Re:Pastebin mirror of code by damaki · · Score: 4, Informative

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

      --
      Stupidity is the root of all evil.
  3. Does DJB insist that the library ... by fishnuts · · Score: 3, 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.

    1. Re:Does DJB insist that the library ... by Anonymous Coward · · 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.

    2. Re:Does DJB insist that the library ... by psmears · · Score: 3, 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, so you can do whatever you want.

    3. Re:Does DJB insist that the library ... by Aighearach · · 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.

  4. Thank you Damien by flyingfsck · · Score: 4, Funny

    This is great news.

    --
    Excuse me, but please get off my Pennisetum Clandestinum, eh!
  5. What about HPN? by Vesvvi · · Score: 3, Insightful

    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.

  6. Re:lame name by Anonymous Coward · · 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.

  7. yes, the other keying option == DES by raymorris · · Score: 3, 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.