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 Anonymous Coward on Wednesday December 11, 2013 @02:11PM (#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.

  • by punman (412350) on Wednesday December 11, 2013 @02: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 raymorris (2726007) on Wednesday December 11, 2013 @07:57PM (#45665821)

    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.

panic: kernel trap (ignored)

Working...