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

Comments

100 lines is meaningless

[Guspaz]

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

[hawguy]

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

[lgw]

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

[punman]

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

[Anonymous Coward]

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

Pastebin mirror of code

[Anonymous Coward]

http://pastebin.com/3YaRWXFs

Re:Pastebin mirror of code

[damaki]

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

Thank you Damien

[flyingfsck]

This is great news.

Re:Does DJB insist that the library ...

[Anonymous Coward]

/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:lame name

[Anonymous Coward]

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

[Aighearach]

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.