4 ms·

Nowadays even many small microcontrollers get AES acceleration so I don't see much reason

by PunchyHamster 9mo ago

avidiax 9mo ago
If you want to encrypt a serial number, you don't want the output to be 256 bits.
- adrian_b 9mo ago
  The size of encrypted data is completely independent of the block size of a block cipher function that is used for data encryption. Nowadays, there is almost never any reason to use for encryption any other modes of operation except CTR or OCB, which do not expand the size of encrypted data. That said, the parent article was less about encryption and more about random number generation, which is done by encrypting a counter value, but you never need to decrypt it again. In RNGs, the block size again does not matter, as the output can be truncated to any desired size.
  - avidiax 9mo ago
    The problem domain is that you want to separately encrypt/decrypt various 32-bit serial numbers. CTR mode turns this into just an XOR operation. That provides very little security. Anyone observing sequential sequence numbers (particularly rollovers) will quickly derive the partial value of the first CTR mode cipher block. A 32-bit cipher, on the other hand, essentially creates a permutation of the entire 32-bit space that's reversible with the key. Ideally, the encrypted value of serial #1 tells you nothing about the value of serial #2, which is the case for practical 32-bit ciphers.
- SAI_Peregrinus 9mo ago
  AES is most often used in a streaming mode, where it's used to generate a keystream. AES alone is useless, it MUST have a mode of operation to provide any security. A streaming mode can then encrypt any number of bits greater than 0. AES-CTR is one of the more common streaming modes.
chowells 9mo ago
Basically all of the use cases in the article don't make sense with AES. That's not because it's AES. That's because its blocks are significantly larger than the data you want to protect. That's the point the article was making: in very specific circumstances, there is practical value in having the cipher output be small.
- fluoridation 9mo ago
  In that case just use CTR mode, no?
  - Joker_vD 9mo ago
    Some people just itch to use something custom and then to have to think about it. Which can bring amazing results, sure, but it can also bring spectacular disasters as well, especially when we're talking about crypto.
    - giantrobot 9mo ago
      The article is less about crypto and more about improving UUID (and IDs in general) with small block ciphers. It's a low impact mechanism to avoid leaking data that UUID by design does leak. It also doesn't require a good source of entropy.
  - 201984 9mo ago
    In the context of encrypting 32 or 64 bit IDs, where there is no nonce, that'd be equivalent to XOR encryption and much weaker than TFA's small block ciphers.
    - adrian_b 9mo ago
      If you really want to encrypt and decrypt 32-bit numbers without having any nonces available, the fastest way on non-microcontroller CPUs remains using the AES instructions. You can exploit the fact that the core of AES consists of 32-bit invertible mixing functions. In order to extend AES to 128-bit, a byte permutation is used, which mixes the bytes of the 32-bit words. The AES instructions are such, that you can cancel the byte permutation. In this case, you can use the AES instructions to encrypt separately four 32-bit words, instead of one 128-bit block. Similarly by canceling the standard byte permutation and replacing it with separate permutations on the 2 halves, you can make the AES instructions independently encrypt two 64-bit words. These AES modifications remain faster than any software cipher. How to cancel the internal permutation and replace it with external shuffle instructions was already described in the Intel white paper published in 2010, at the launch of Westmere, the first CPU with AES instructions.
kpcyrd 9mo ago
The ch32v003 implements RISC-V without the M extension, meaning there's not even a MUL/DIV instruction. Out of all micro controllers I've worked with, only a single one had AES cpu instructions.

Nowadays even many small microcontrollers get AES acceleration so I don't see much reason

avidiax 9mo ago

If you want to encrypt a serial number, you don't want the output to be 256 bits.

adrian_b 9mo ago
The size of encrypted data is completely independent of the block size of a block cipher function that is used for data encryption. Nowadays, there is almost never any reason to use for encryption any other modes of operation except CTR or OCB, which do not expand the size of encrypted data. That said, the parent article was less about encryption and more about random number generation, which is done by encrypting a counter value, but you never need to decrypt it again. In RNGs, the block size again does not matter, as the output can be truncated to any desired size.
- avidiax 9mo ago
  The problem domain is that you want to separately encrypt/decrypt various 32-bit serial numbers. CTR mode turns this into just an XOR operation. That provides very little security. Anyone observing sequential sequence numbers (particularly rollovers) will quickly derive the partial value of the first CTR mode cipher block. A 32-bit cipher, on the other hand, essentially creates a permutation of the entire 32-bit space that's reversible with the key. Ideally, the encrypted value of serial #1 tells you nothing about the value of serial #2, which is the case for practical 32-bit ciphers.
SAI_Peregrinus 9mo ago
AES is most often used in a streaming mode, where it's used to generate a keystream. AES alone is useless, it MUST have a mode of operation to provide any security. A streaming mode can then encrypt any number of bits greater than 0. AES-CTR is one of the more common streaming modes.

chowells 9mo ago

Basically all of the use cases in the article don't make sense with AES. That's not because it's AES. That's because its blocks are significantly larger than the data you want to protect. That's the point the article was making: in very specific circumstances, there is practical value in having the cipher output be small.

fluoridation 9mo ago
In that case just use CTR mode, no?
- Joker_vD 9mo ago
  Some people just itch to use something custom and then to have to think about it. Which can bring amazing results, sure, but it can also bring spectacular disasters as well, especially when we're talking about crypto.
  - giantrobot 9mo ago
    The article is less about crypto and more about improving UUID (and IDs in general) with small block ciphers. It's a low impact mechanism to avoid leaking data that UUID by design does leak. It also doesn't require a good source of entropy.
- 201984 9mo ago
  In the context of encrypting 32 or 64 bit IDs, where there is no nonce, that'd be equivalent to XOR encryption and much weaker than TFA's small block ciphers.
  - adrian_b 9mo ago
    If you really want to encrypt and decrypt 32-bit numbers without having any nonces available, the fastest way on non-microcontroller CPUs remains using the AES instructions. You can exploit the fact that the core of AES consists of 32-bit invertible mixing functions. In order to extend AES to 128-bit, a byte permutation is used, which mixes the bytes of the 32-bit words. The AES instructions are such, that you can cancel the byte permutation. In this case, you can use the AES instructions to encrypt separately four 32-bit words, instead of one 128-bit block. Similarly by canceling the standard byte permutation and replacing it with separate permutations on the 2 halves, you can make the AES instructions independently encrypt two 64-bit words. These AES modifications remain faster than any software cipher. How to cancel the internal permutation and replace it with external shuffle instructions was already described in the Intel white paper published in 2010, at the launch of Westmere, the first CPU with AES instructions.

kpcyrd 9mo ago

The ch32v003 implements RISC-V without the M extension, meaning there's not even a MUL/DIV instruction. Out of all micro controllers I've worked with, only a single one had AES cpu instructions.