Add AES encrypt/decrypt example by Firstyear · Pull Request #492 · parallaxsecond/rust-tss-esapi

Firstyear · 2024-02-04T05:17:10Z

This adds an example of how to use AES-128-CBC encryption and decryption with a TPM.

Firstyear · 2024-02-04T05:18:07Z

Please note there are two comments in the code that we should probably discuss. First is exposing the AES block size from the AesKeyBits enum. The second is if we should add pkcs7 padding to the crate to prevent people from "rolling their own".

ionut-arm

Thank you for the effort of putting these examples together!

tss-esapi/examples/aes_encrypt_decrypt.rs

ionut-arm · 2024-02-18T22:29:38Z

tss-esapi/examples/aes_encrypt_decrypt.rs

+    // REVIEW NOTE: Tss-esapi likely should expose these as constants from AesKeyBits::Aes128
+    // to prevent ambiguity!
+    const AES_BLOCK_SIZE: usize = 16;


I agree that we need to expose this constant from somewhere in the code (and I'd welcome it as a separate commit in this PR!), but I disagree it should have anything to do with AesKeyBits because the block size for AES is not tied to key size.

Given that this would be an addition to what the spec provides, the abstraction module would probably be the best place to have it, perhaps as a method on this. But I wouldn't be opposed to also adding it as a method on SymmetricCipherParameters, for example. We just need to figure out what that method should return for Xor and Null, and document them.

See comment below.

Wait what? I thought that block size was tied to the AESKeyBit size? IE AES-128 requires a 128bit key and a 16 byte block, where AES-256 requires a 256 bit key and a 32 byte block? I'm happy to be wrong, but all my other experience with openssl etc has the above assumptions enshrined.

See NIST FIPS 197, paragraph three of section 1, first paragraph of section 3.1 ... Rijndael accepts different block sizes, but AES does not.

I'm not that great at digging through OpenSSL docs, the best I found was this.

Ahhh yes, it's related to cipher selection not key. Maybe it should be on https://docs.rs/tss-esapi/latest/tss_esapi/interface_types/algorithm/enum.SymmetricMode.html or https://docs.rs/tss-esapi/latest/tss_esapi/interface_types/algorithm/enum.SymmetricAlgorithm.html 🤔

AES-GCM makes it tricky since it's block size is 1, but I think the way we have the parameters laid out we need the SymmetricMode + Key to really know what the block size is.

I'm not actually sure if in the context of TPMs the same applies. I've skimmed a bit through the spec, couldn't find much, I'll need to test it.

ionut-arm · 2024-02-18T22:34:19Z

tss-esapi/examples/aes_encrypt_decrypt.rs

+    // REVIEW NOTE: Should we added PKCS7 padding as a function to MaxBuffer to prevent
+    // people needing to "roll their own"?


Yeah, agree, that would be good to have! But again, this seems like an abstraction kind of thing, perhaps it could go in the Cipher module - something like PaddedBuffer? We can then reference these new handy features in the documentation for the encryption/decryption methods, and, of course, in this example.

Actually, it strikes me that we could (maybe even should) offload these details to the cipher RustCrypto traits. For example if we allow Block, or a vector of Blocks, to be converted to MaxBuffer, then padding is free for us, and we can easily get the block size. This could be a first step towards tighter integration with those traits.

What do you think?

Yeah, I think that's a good idea. But I suspect that is it's own PR?

Still even so, this example has highlighted a few places the api we have can be better :)

Having that as its own PR makes sense! And we can update this example when that's pushed.

I'm not even sure we'd need that since https://docs.rs/block-padding/0.3.2/block_padding/struct.Pkcs7.html already has .as_slice and we have https://docs.rs/tss-esapi/latest/tss_esapi/structures/struct.MaxBuffer.html#impl-TryFrom%3C%26%5Bu8%5D%3E-for-MaxBuffer

So we could just swap the padding process here.

Actually, reading that API it seems to be really limited and complex.

We would need to take the array of bytes, then iterate over it as chunks exact with https://doc.rust-lang.org/std/slice/struct.ChunksExact.html to match the block size.

We need this because we need to check the remainder case. If the remainder is empty, we need to append another block because pkcs7 always pads to avoid ambiguity. So that means we can't just look at the vec and grow it if needed, we have to clone the full input everytime because blocks are effectively an array.

And then a vec of generic array can't do to_slice, so we have to iterate again to make a new vec that we can try_from for max_buffer.

So unless I'm really overlooking something obvious, this seems like a really rough api to want to interface with.

tss-esapi/examples/aes_encrypt_decrypt.rs

Superhepper · 2024-04-03T18:54:39Z

Have you forgot to sign the commits?

Firstyear · 2024-04-03T22:41:57Z

Have you forgot to sign the commits?

Very likely :) But it wasn't ready to merge yet either.

Firstyear · 2024-05-01T05:32:07Z

Okay, I've rebased an updated to latest main. I think that pkcs7/padding is "out of scope" for this crate, and I'm going to make an example of exposing the TPM via rust-crypto interfaces so we can inherit their padding options. I'll hopefully have this example "converted" shortly as a POC.

Firstyear · 2024-07-22T02:27:00Z

This has finally come up again so I should be looping back to improve this shortly :)

tss-esapi/examples/aes_encrypt_decrypt_rust_crypto.rs

mcr · 2026-01-01T19:22:28Z

rebase and try again?

Firstyear · 2026-01-07T06:13:09Z

Rebased, thanks!

This adds an example of how to use AES-128-CBC encryption and decryption with a TPM. Signed-off-by: William Brown <william.brown@suse.com>

wiktor-k

This is a well-done example 👌

I'm wondering though whether the RustCrypto trait implementation should be moved to the main crate. It seems quite useful and generic so instead of folks copying that part of the code they could use our rustcrypto feature and get these traits...

Pinging our RustCrypto guru @baloo 🐻

wiktor-k · 2026-01-07T12:16:14Z

tss-esapi/examples/aes_encrypt_decrypt.rs

+                .load(primary.key_handle, enc_private.clone(), public.clone())
+                .unwrap();
+
+            let decrypt = true;


I'm very happy that you've made this explicit and I'm wondering how whether we should be providing encrypt_2 and decrypt_2 as two separate functions just for the sake of users 😅

That's of course a totally different subject, nothing to do here, carry on! 🚀

wiktor-k · 2026-01-07T12:17:15Z

tss-esapi/examples/aes_encrypt_decrypt_rust_crypto.rs

+        })
+        .unwrap();
+
+    /*


I think this entire section can be removed 🤔

wiktor-k · 2026-01-07T12:18:27Z

tss-esapi/examples/aes_encrypt_decrypt_rust_crypto.rs

+        &mut self,
+        f: impl cipher::BlockClosure<BlockSize = Self::BlockSize>,
+    ) {
+        // No errors? I'll raise an issue.


I have the same issue with RustCrypto traits and some of them started getting error capabilities 😅 Is there a backing ticket already?

I don't know if those traits are really meant for being used with a secret abstracted away. They are designed with local computation where you have access to the cipher state.

baloo · 2026-01-07T17:20:57Z

tss-esapi/examples/aes_encrypt_decrypt_rust_crypto.rs

+        panic!("Should not be empty");
+    }
+
+    const AES_BLOCK_SIZE: usize = 16;


Suggested change

const AES_BLOCK_SIZE: usize = 16;

const AES_BLOCK_SIZE: usize = aes::Aes128::BlockSize::USIZE;

https://docs.rs/aes/latest/aes/struct.Aes128.html#associatedtype.BlockSize

Will need use cipher::BlockSizeUser and cipher::Unsigned if not already in scope.

(absolute nitpick)

mcr · 2026-01-07T19:21:58Z

I'm wondering though whether the RustCrypto trait implementation should be moved to the main crate. It seems quite useful and generic so instead of folks copying that part of the code they could use our rustcrypto feature and get these traits...

Sure, but make a new PR.

mcr

Just the changes baloo asked for.

ionut-arm reviewed Feb 18, 2024

View reviewed changes

Firstyear force-pushed the 20240203-aes-encrypt-decrypt-example branch from afdff20 to ad678ed Compare February 20, 2024 03:17

ionut-arm reviewed Feb 21, 2024

View reviewed changes

tss-esapi/examples/aes_encrypt_decrypt.rs Show resolved Hide resolved

Firstyear force-pushed the 20240203-aes-encrypt-decrypt-example branch from ad678ed to 32a3338 Compare May 1, 2024 05:28

wiktor-k reviewed Jul 22, 2024

View reviewed changes

tss-esapi/examples/aes_encrypt_decrypt_rust_crypto.rs Show resolved Hide resolved

mcr approved these changes Jan 1, 2026

View reviewed changes

Firstyear force-pushed the 20240203-aes-encrypt-decrypt-example branch from ce6dea3 to dbb4fc0 Compare January 7, 2026 06:13

Add AES encrypt/decrypt example

a986b26

This adds an example of how to use AES-128-CBC encryption and decryption with a TPM. Signed-off-by: William Brown <william.brown@suse.com>

Firstyear force-pushed the 20240203-aes-encrypt-decrypt-example branch from dbb4fc0 to a986b26 Compare January 7, 2026 06:15

wiktor-k approved these changes Jan 7, 2026

View reviewed changes

baloo reviewed Jan 7, 2026

View reviewed changes

mcr suggested changes Jan 7, 2026

View reviewed changes

		// REVIEW NOTE: Should we added PKCS7 padding as a function to MaxBuffer to prevent
		// people needing to "roll their own"?

	const AES_BLOCK_SIZE: usize = 16;
	const AES_BLOCK_SIZE: usize = aes::Aes128::BlockSize::USIZE;

Conversation

Firstyear commented Feb 4, 2024

Uh oh!

Firstyear commented Feb 4, 2024

Uh oh!

ionut-arm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ionut-arm Feb 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Superhepper commented Apr 3, 2024

Uh oh!

Firstyear commented Apr 3, 2024

Uh oh!

Firstyear commented May 1, 2024

Uh oh!

Firstyear commented Jul 22, 2024

Uh oh!

Uh oh!

mcr commented Jan 1, 2026

Uh oh!

Firstyear commented Jan 7, 2026

Uh oh!

wiktor-k left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

baloo Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mcr commented Jan 7, 2026

Uh oh!

mcr left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

ionut-arm Feb 20, 2024 •

edited

Loading

baloo Jan 7, 2026 •

edited

Loading