[ 
https://issues.apache.org/jira/browse/SSHD-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141526#comment-17141526
 ] 

Matt Sicker commented on SSHD-1017:
-----------------------------------

After letting this problem percolate, I think I've figured out the equivalence. 
To match the same usage in OpenSSH, I think it would suffice to use the RFC 
7539 form of ChaCha20-Poly1305 like so:

* Cipher initialized with a counter value of 0 and a nonce formed by four zero 
bytes (the upper bytes of the counter in the pre-standard ChaCha) followed by 
the eight-byte little endian encoding of the packet sequence number.
* This will initialize the Poly1305 mac appropriately and advance the counter 
to 1 as OpenSSH specifies.

Everything else should hopefully fall into place here. The packet length 
encryption/decryption uses the same nonce and a counter value of 0, but only 
using ChaCha20 without authentication.

The biggest difference between this encoding and the previous AES/GCM one 
(besides the packet length encryption) is how the initial nonce is constructed. 
In AES/GCM, this starts with the generated IV from the handshake, then it 
increments that value to correlate with the packet sequence number. In this new 
ChaCha20-Poly1305 encoding, the generated IV is ignored entirely, and a fully 
predictable nonce is created. The way that GCM is specified allows for using 
that same strategy, but that isn't how it ended up being used in the standard.

> Add support for chacha20-poly1...@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.
> The cipher is available in Java 11 natively and is also provided by 
> Bouncycastle with a pure Java implementation fallback.
> 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-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Reply via email to