Support AesGcm cipher #1364

scott-xu · 2024-03-27T17:17:55Z

This PR adds support for aes128-gcm@openssh.com, aes256-gcm@openssh.com ciphers.
This PR does not add chacha20-poly1305@openssh.com cipher.
Fix #792 Fix #1356 Fix #774 Fix #773 Fix #555 Fix #477 Fix #994

… SymmetricCipher to BlockCipher

…just like other ciphers

src/Renci.SshNet/Security/Cryptography/Ciphers/AesGcmCipher.cs

WojciechNagorski · 2024-03-31T13:06:58Z

I will review in next few days.

Rob-Hague

The OpenSSH version of AES-GCM (https://github.com/openssh/openssh-portable/blob/43e7c1c07cf6aae7f4394ca8ae91a3efc46514e2/PROTOCOL#L82) states:

Additionally, if AES-GCM is selected as the cipher [...] there doesn't have to be a matching MAC.

could you please implement that?

Rob-Hague · 2024-04-01T12:34:21Z

src/Renci.SshNet/Security/Cryptography/Ciphers/AesGcmCipher.cs

+        {
+            // [inbound sequence][packet length field][padding length field sz][payload][random paddings][Authenticated TAG]
+            // [-----4 bytes----][----4 bytes(offset)][------------------Cipher Text--------------------][-------TAG-------]
+            var packetLengthField = new ReadOnlySpan<byte>(input, offset - 4, 4);


It's quite unpleasant/unintuitive to assume there is data to process in input before offset. Is there a nicer way to do it?

Could packet_length (i.e. the associated data) start at offset?

At the very least, there should be some explicit /// xmldoc here explaining the usage.

I understand your concern. Typically, the cipher only decrypts "cipher text" which starts from offset and ends before MAC (tag). However, AesGcm requires the packet_length (aad) and MAC (tag) to do the decryption and authentication which is before and after the cipher text.
The Decrypt(...) method of AesGcm is called (and only called) from https://github.com/sshnet/SSH.NET/blob/develop/src/Renci.SshNet/Session.cs#L1302 which guarantees the data layout.

The Decrypt(...) method of AesGcm is called (and only called) from https://github.com/sshnet/SSH.NET/blob/develop/src/Renci.SshNet/Session.cs#L1302 which guarantees the data layout.

Still, adding a bounds check could be a good thing for future proofing.

There are some options here:

keep it as is but add bounds check

in Session class, treat aead cipher as special and set offset before packet_length and include MAC(tag) in length

in Session class, treat aead cipher as special and set offset to 0 and include all in length (consider that ChaCha20Poly1305 requires sequence block if I read the spec correctly)

Just checked the source code of the constructor about ReadOnlySpan<T>. It does check the bounds:

It casts the start to ulong/uint to make sure it is positive.

It checks the length to no larger than array length - offset.

/// <summary> /// Creates a new read-only span over the portion of the target array beginning /// at 'start' index and ending at 'end' index (exclusive). /// </summary> /// <param name="array">The target array.</param> /// <param name="start">The index at which to begin the read-only span.</param> /// <param name="length">The number of items in the read-only span.</param> /// <remarks>Returns default when <paramref name="array"/> is null.</remarks> /// <exception cref="System.ArgumentOutOfRangeException"> /// Thrown when the specified <paramref name="start"/> or end index is not in the range (<0 or >Length). /// </exception> [MethodImpl(MethodImplOptions.AggressiveInlining)] public ReadOnlySpan(T[]? array, int start, int length) { if (array == null) { if (start != 0 || length != 0) ThrowHelper.ThrowArgumentOutOfRangeException(); this = default; return; // returns default } #if TARGET_64BIT // See comment in Span<T>.Slice for how this works. if ((ulong)(uint)start + (ulong)(uint)length > (ulong)(uint)array.Length) ThrowHelper.ThrowArgumentOutOfRangeException(); #else if ((uint)start > (uint)array.Length || (uint)length > (uint)(array.Length - start)) ThrowHelper.ThrowArgumentOutOfRangeException(); #endif _pointer = new ByReference<T>(ref Unsafe.Add(ref MemoryMarshal.GetArrayDataReference(array), (nint)(uint)start /* force zero-extension */)); _length = length; }

There are some options here:

keep it as is but add bounds check

in Session class, treat aead cipher as special and set offset before packet_length and include MAC(tag) in length

in Session class, treat aead cipher as special and set offset to 0 and include all in length (consider that ChaCha20Poly1305 requires sequence block if I read the spec correctly)

Personally I prefer option1, because it is consistent for all kinds of ciphers. No special handing in Session class. The current implementation in #1369 is option2. It defers the issue when add ChaCha20Poly1305 in the future.

Life will be much easier if there's no such many options 🙃

Changed back to option1 with some tiny enhancements in the latest commit.

Rob-Hague · 2024-04-01T12:34:56Z

src/Renci.SshNet/Security/Cryptography/Ciphers/AesGcmCipher.cs

+            // [-----4 bytes----][----4 bytes(offset)][------------------Cipher Text--------------------][-------TAG-------]
+            var packetLengthField = new ReadOnlySpan<byte>(input, offset - 4, 4);
+            var cipherText = new ReadOnlySpan<byte>(input, offset, length);
+            var tag = new ReadOnlySpan<byte>(input, offset + length, TagSize);


Same here, in assuming there is space beyond offset + length

scott-xu · 2024-04-01T13:28:23Z

The OpenSSH version of AES-GCM (https://github.com/openssh/openssh-portable/blob/43e7c1c07cf6aae7f4394ca8ae91a3efc46514e2/PROTOCOL#L82) states:
Additionally, if AES-GCM is selected as the cipher [...] there doesn't have to be a matching MAC.
could you please implement that?

I think the "matching MAC" means the matching MAC algorithm. See code here: https://github.com/sshnet/SSH.NET/pull/1364/files#diff-8cb58eb5577b3c26c820c320ea463952036f2aeadf28470a6265575168756164R1520-R1528

Rob-Hague · 2024-04-01T13:38:22Z

That's good but I think if we offer:

Ciphers: aes128-gcm@openssh.com
HMACs: hmac-sha2-256

and they offer:

Ciphers: aes128-gcm@openssh.com
HMACs: hmac-sha1

then we are going to error out here despite not using the HMAC

SSH.NET/src/Renci.SshNet/Security/KeyExchange.cs

Lines 99 to 107 in db3d7e8

    
           // Determine client hmac algorithm 
        
           var clientHmacAlgorithmName = (from b in session.ConnectionInfo.HmacAlgorithms.Keys 
        
                                          from a in message.MacAlgorithmsClientToServer 
        
                                          where a == b 
        
                                          select a).FirstOrDefault(); 
        
           if (string.IsNullOrEmpty(clientHmacAlgorithmName)) 
        
           { 
        
               throw new SshConnectionException("Client HMAC algorithm not found", DisconnectReason.KeyExchangeFailed); 
        
           }

…d tag field in offset and length when call AesGcm's `Decrypt(...)` method. Do not determine HMAC if cipher is AesGcm during kex.

WojciechNagorski · 2024-04-04T04:37:03Z

@Rob-Hague Can I ask you for a review? My time is limited now.

scott-xu · 2024-04-04T08:53:36Z

I renamed the source branch and this PR is closed automatically. I just created another PR #1369

zybexXL · 2024-04-04T09:34:33Z

You mean #1369.
This PR could be reopened to keep the existing comment history.

scott-xu · 2024-04-04T09:48:11Z

@zybexXL thanks! I corrected the comments just now. Unfortunately, this PR cannot be reopened. The button is grayed out.

zybexXL · 2024-04-04T09:50:21Z

Admins/Moderators should be able to reopen it.

Rob-Hague · 2024-04-04T10:37:31Z

Presumably, you will at least need to restore the branch ref with the same name as before

scott-xu · 2024-04-04T10:50:55Z

The PR is closed but this thread is not deleted. The history is not lost.
Is there anything can't be done without this PR to reopen?

scott-xu added 6 commits March 27, 2024 21:35

Init AeadCipher

8b5c819

Move AeadCipher to parent folder. Move EncryptBlock/DecryptBlock from…

4d160ca

… SymmetricCipher to BlockCipher

simplify parameter name

7546a5a

Implement AesGcmCipher

270fb96

Merge branch 'develop' into aes-gcm-and-chacha20-poly1305

7a6b334

Update README

1059b68

scott-xu changed the title ~~Aes gcm and chacha20 poly1305~~ Support AesGcm cipher Mar 28, 2024

scott-xu marked this pull request as ready for review March 28, 2024 01:05

scott-xu requested review from drieseng and WojciechNagorski as code owners March 28, 2024 01:05

scott-xu requested a review from Rob-Hague March 28, 2024 01:06

scott-xu marked this pull request as draft March 31, 2024 04:10

scott-xu added 2 commits March 31, 2024 12:14

Remove protected IV from AeadCipher; Set offset to outbound sequence …

fe26b65

…just like other ciphers

Rename associatedData to packetLengthField

1b92a6a

scott-xu marked this pull request as ready for review March 31, 2024 05:50

zybexXL reviewed Mar 31, 2024

View reviewed changes

src/Renci.SshNet/Security/Cryptography/Ciphers/AesGcmCipher.cs Show resolved Hide resolved

Use Span<byte> to avoid unnecessary allocations

7377cbe

Use Span to improve performance when IncrementCounter()

cdbe822

Rob-Hague reviewed Apr 1, 2024

View reviewed changes

scott-xu marked this pull request as draft April 1, 2024 14:11

scott-xu added 3 commits April 2, 2024 09:53

Add IsAead property to CipherInfo. Include packet length field an…

65ad16a

…d tag field in offset and length when call AesGcm's `Decrypt(...)` method. Do not determine HMAC if cipher is AesGcm during kex.

Fix build

3336d3d

Fix UT

37a16bf

scott-xu marked this pull request as ready for review April 2, 2024 11:11

Merge branch 'develop' into aes-gcm-and-chacha20-poly1305

fdc8f49

scott-xu self-assigned this Apr 4, 2024

scott-xu closed this Apr 4, 2024

scott-xu deleted the aes-gcm-and-chacha20-poly1305 branch April 4, 2024 08:31

scott-xu mentioned this pull request Apr 4, 2024

Add support for AEAD AES 128/256 GCM Ciphers (.NET 6.0 onward only) #1369

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support AesGcm cipher #1364

Support AesGcm cipher #1364

scott-xu commented Mar 27, 2024 •

edited

Loading

WojciechNagorski commented Mar 31, 2024

Rob-Hague left a comment

Rob-Hague Apr 1, 2024

scott-xu Apr 1, 2024 •

edited

Loading

zybexXL Apr 1, 2024

scott-xu Apr 1, 2024

scott-xu Apr 2, 2024

scott-xu Apr 7, 2024

scott-xu Apr 8, 2024

Rob-Hague Apr 1, 2024

scott-xu commented Apr 1, 2024

Rob-Hague commented Apr 1, 2024

WojciechNagorski commented Apr 4, 2024

scott-xu commented Apr 4, 2024 •

edited

Loading

zybexXL commented Apr 4, 2024

scott-xu commented Apr 4, 2024

zybexXL commented Apr 4, 2024 •

edited

Loading

Rob-Hague commented Apr 4, 2024

scott-xu commented Apr 4, 2024

Support AesGcm cipher #1364

Support AesGcm cipher #1364

Conversation

scott-xu commented Mar 27, 2024 • edited Loading

WojciechNagorski commented Mar 31, 2024

Rob-Hague left a comment

Choose a reason for hiding this comment

Rob-Hague Apr 1, 2024

Choose a reason for hiding this comment

scott-xu Apr 1, 2024 • edited Loading

Choose a reason for hiding this comment

zybexXL Apr 1, 2024

Choose a reason for hiding this comment

scott-xu Apr 1, 2024

Choose a reason for hiding this comment

scott-xu Apr 2, 2024

Choose a reason for hiding this comment

scott-xu Apr 7, 2024

Choose a reason for hiding this comment

scott-xu Apr 8, 2024

Choose a reason for hiding this comment

Rob-Hague Apr 1, 2024

Choose a reason for hiding this comment

scott-xu commented Apr 1, 2024

Rob-Hague commented Apr 1, 2024

WojciechNagorski commented Apr 4, 2024

scott-xu commented Apr 4, 2024 • edited Loading

zybexXL commented Apr 4, 2024

scott-xu commented Apr 4, 2024

zybexXL commented Apr 4, 2024 • edited Loading

Rob-Hague commented Apr 4, 2024

scott-xu commented Apr 4, 2024

scott-xu commented Mar 27, 2024 •

edited

Loading

scott-xu Apr 1, 2024 •

edited

Loading

scott-xu commented Apr 4, 2024 •

edited

Loading

zybexXL commented Apr 4, 2024 •

edited

Loading