[
https://issues.apache.org/jira/browse/SSHD-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17109606#comment-17109606
]
Matt Sicker edited comment on SSHD-506 at 5/17/20, 6:44 PM:
------------------------------------------------------------
I decided to cheat a little and go read the source code in OpenSSH. I think
it's given me a couple ideas on refactoring what I've written to better match
how they implement this. It seems like any implementation of SSH follows a
fairly similar architecture that mirrors the SSH standard, and that has made it
increasingly easy for me to jump around all these different implementations.
Due to a limitation in the Java crypto API, I'll have to keep track of the
secret key when using GCM so I can re-init the cipher with the updated IV on
each packet (OpenSSL apparently allows you to directly update an IV using the
envelope cipher function for setting an IV; yay for low level operations we
can't access). And as far as I can tell, OpenSSH seems to use the IV as
calculated during key exchange, and then it updates the IV for each packet by
incrementing the 8 upper bytes as an unsigned long (the lower 4 bytes remain
fixed until a re-key).
Based on my read through so far, I think I've got this mostly figured out. I
think I initially confused a couple things: how to update the nonce properly
for OpenSSH compatibility, and how to treat the packet length in this mode
(this is more of an "off by 4" error rather than "off by 1").
Finally, some good news: the use of AES/GCM in the RFC works naturally with how
the Java API works (appending the authentication tag (AT) after the ciphertext
automatically), and the processing of the packet length group of bytes
basically gets changed from calling {{update}} to {{updateAAD}} to leave it
unencrypted but still calculated in the AT. The only API mis-match is the
aforementioned inability to directly update the IV of a cipher without
re-initializing it with the key as well. To avoid re-computing the key on every
packet, I'll have to cache it.
was (Author: jvz):
I decided to cheat a little and go read the source code in OpenSSH. I think
it's given me a couple ideas on refactoring what I've written to better match
how they implement this. It seems like any implementation of SSH follows a
fairly similar architecture that mirrors the SSH standard, and that has made it
increasingly easy for me to jump around all these different implementations.
Due to a limitation in the Java crypto API, I'll have to keep track of the
secret key when using GCM so I can re-init the cipher with the updated IV on
each packet (OpenSSL apparently allows you to directly update an IV using the
envelope cipher function for setting an IV; yay for low level operations we
can't access). And as far as I can tell, OpenSSH seems to use the IV as
calculated during key exchange, and then it updates the IV for each packet by
incrementing the 8 upper bytes as an unsigned long (the lower 4 bytes remain
fixed until a re-key).
Based on my read through so far, I think I've got this mostly figured out. I
think I initially confused a couple things: how to update the nonce properly
for OpenSSH compatibility, and how to treat the packet length in this mode
(this is more of an "off by 4" error rather than "off by 1").
> Add support for aes128/256-gcm ciphers
> --------------------------------------
>
> Key: SSHD-506
> URL: https://issues.apache.org/jira/browse/SSHD-506
> Project: MINA SSHD
> Issue Type: Improvement
> Reporter: Lyor Goldstein
> Priority: Major
>
> See:
> * [rfc5647|https://tools.ietf.org/html/rfc5647]
> *
> [draft-igoe-secsh-aes-gcm-01|https://tools.ietf.org/html/draft-igoe-secsh-aes-gcm-01]
> * [OpenSSH v6.2|http://www.openssh.com/txt/release-6.2]
> * [JAVA AES 256 GCM encrypt/decrypt
> example|https://javainterviewpoint.com/java-aes-256-gcm-encryption-and-decryption/]
> - especially the usage of {{GCMParameterSpec}} to initialize the cipher
> * [OpenJDK 8 AESCipher.java source
> code|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/AESCipher.java]
> ** See also
> [CipherCore.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/CipherCore.java],
>
> [FeedbackCipher.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/FeedbackCipher.java],
>
> [GaloisCounterMode.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java]
--
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
