Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: CryptoEngine.cpp questions & suggestions #5543

Open
esev opened this issue Dec 10, 2024 · 0 comments
Open

[Feature Request]: CryptoEngine.cpp questions & suggestions #5543

esev opened this issue Dec 10, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@esev
Copy link
Contributor

esev commented Dec 10, 2024

Platform

Cross-Platform

Description

Original: https://discord.com/channels/867578229534359593/1022240589091192853/1313927254400569355

@jp-bennett FYI

In case this is useful: When reimplementing the PKI encryption in my integration there were a couple parts in the firmware that were unclear at first.

  • The nonce uint32/64 values are all stored in little-endian format. I'm not super familiar with the hardware side, so I had to look that up. It'd be helpful to have a comment about that.
  • I don't understand why the packetId is a uint64 in the nonce generation code. It seems like it should be a uint32 as the most significant 32-bits are overwritten by extraNonce.
  • I wasn't sure why there is an if (extraNonce). Why is the memcpy conditional? Are there cases where extraNonce isn't supplied and where the packetId value is larger than 32-bits?
  • It would be nice if the constants for M (8) & nonce size (13) were given names in CryptoEngine.cpp. The comment about L=2 was helpful in aes-ccm.cpp, as were the names of the function parameters. I just think it would be clearer to have those as named variables or comments in CryptoEngine.cpp.
  • I got confused about what auth was being used for. I thought it was the "additional authenticated data" found in AEAD since space was allocated right after it for the extra nonce. It wasn't immediately clear that this was the output of aes-ccm, when encrypting, and not an input. authTag might avoid ambiguity. Maybe just a little packet header ASCII art diagram would clear it up too.

Once I figured out those bits, it interoperated perfectly with github.com/pschlump/AesCCM

@esev esev added the enhancement New feature or request label Dec 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant