You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Matt Sicker (Jira)" <ji...@apache.org> on 2020/10/19 15:30:00 UTC
[jira] [Comment Edited] (SSHD-1017) Add support for
chacha20-poly1305@openssh.com
[ https://issues.apache.org/jira/browse/SSHD-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17216817#comment-17216817 ]
Matt Sicker edited comment on SSHD-1017 at 10/19/20, 3:29 PM:
--------------------------------------------------------------
I'd expect any production implementation to work like the public domain (donna) one. Java doesn't expose enough numerical functionality to implement the more optimized variants directly (they need to be done via native code), but the 32-bit variant can be implemented in pure Java (they're all based on unsigned arithmetic, so Java is limiting even for the 64-bit variant due to a lack of access to the carry flag from long multiplication). IIRC, I think BouncyCastle has a javax.crypto.Mac provider for Poly1305.
As for de facto standards, I counter with libssh.org which is not the same project as OpenSSH, yet they've published SSH extensions that OpenSSH adopted as well. Plus, based on how glacial the IETF working group processes appear to be, it seems to make sense to test out potential RFCs as extensions before even proposing them (had that been done for AES/GCM, then the RFC for it might've actually been implemented rather than having an ambiguity in the standard that was fixed in the OpenSSH extension; the OpenSSH chacha20 extension at least tried implementing ahead of time, but maybe too early).
was (Author: jvz):
I'd expect any production implementation to work like the public domain (donna) one. Java doesn't expose enough numerical functionality to implement the more optimized variants directly (they need to be done via native code), but the 32-bit variant can be implemented in pure Java. IIRC, I think BouncyCastle has a javax.crypto.Mac provider for Poly1305.
As for de facto standards, I counter with libssh.org which is not the same project as OpenSSH, yet they've published SSH extensions that OpenSSH adopted as well. Plus, based on how glacial the IETF working group processes appear to be, it seems to make sense to test out potential RFCs as extensions before even proposing them (had that been done for AES/GCM, then the RFC for it might've actually been implemented rather than having an ambiguity in the standard that was fixed in the OpenSSH extension; the OpenSSH chacha20 extension at least tried implementing ahead of time, but maybe too early).
> Add support for chacha20-poly1305@openssh.com
> ---------------------------------------------
>
> Key: SSHD-1017
> URL: https://issues.apache.org/jira/browse/SSHD-1017
> Project: MINA SSHD
> Issue Type: New Feature
> Reporter: Matt Sicker
> Priority: Major
>
> See [protocol details|https://github.com/openbsd/src/blob/master/usr.bin/ssh/PROTOCOL.chacha20poly1305].
> * [RFC 7539|https://tools.ietf.org/html/rfc7539] describes the ChaCha20-Poly1305 algorithm.
> * [Dropbear implementation|https://github.com/mkj/dropbear/blob/master/chachapoly.c]
> * [OpenSSH implementation|https://github.com/openbsd/src/blob/master/usr.bin/ssh/cipher-chachapoly-libcrypto.c]
> The cipher is provided by Bouncycastle.
> As a bonus, this could potentially be adapted to propose an equivalent AES/GCM cipher encoding to how OpenSSH implements this ChaCha20-Poly1305 cipher.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org