Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by Unknown on 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!"

28 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 c0lo · · Score: 2

      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.

      --
      Questions raise, answers kill. Raise questions to stay alive.
    2. Re:100 lines is meaningless by Etcetera · · Score: 2

      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.

      --
      Hire a Linux system administrator, systems engineer,
    3. 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

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

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

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

    7. Re:100 lines is meaningless by DMUTPeregrine · · Score: 2

      Damien Miller wrote this implementation, not DJB. DJB designed the ciphers and wrote the reference implementations. DJM and DJB are two different people.

      --
      Not a sentence!
    8. Re:100 lines is meaningless by lgw · · Score: 2

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

      --
      Socialism: a lie told by totalitarians and believed by fools.
    9. 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

    http://pastebin.com/3YaRWXFs

    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. Not less than 100 lines by Anonymous Coward · · 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).

    1. Re:Not less than 100 lines by ConstantineM · · Score: 2

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

  4. 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 Njovich · · Score: 2

      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)

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

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

      --
      Need to type accents and special characters in Windows? Use FrKeys
    4. 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.

    5. Re:Does DJB insist that the library ... by Bacon+Bits · · Score: 2

      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.

      --
      The road to tyranny has always been paved with claims of necessity.
  5. Thank you Damien by flyingfsck · · Score: 4, Funny

    This is great news.

    --
    Excuse me, but please get off my Pennisetum Clandestinum, eh!
  6. 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.

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

  8. But NOT des(des(des())). Don't do that! by raymorris · · Score: 2

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

    1. Re:But NOT des(des(des())). Don't do that! by maxwell+demon · · 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've run a rot13 on it before sending.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    2. Re:But NOT des(des(des())). Don't do that! by amorsen · · Score: 2

      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 inner method always starts its output with a known pattern, it can really mess up your outer method). Therefore, always encrypt FIRST with the algorithm you trust most, and NEVER use the same key for both methods.

      --
      Finally! A year of moderation! Ready for 2019?
  9. Re:knowing DJB, I don't trust it by amorsen · · Score: 2

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