search

intel / intel-ipsec-mb

Intel(R) Multi-Buffer Crypto for IPSec
BSD 3-Clause "New" or "Revised" License
289 stars 87 forks source link

Block count may be incremented incorrectly in AES-CTR #43

Closed pablodelara closed 4 years ago

pablodelara commented 4 years ago

AES-CTR algorithm used in IPSec (cipher_mode = AES_CNTR) uses a counter block with 4 bytes for block count, according to the following RFC: https://tools.ietf.org/html/rfc3686#section-2.1

AES-CTR algorithm used in PDCP (AES_CNTR_BITLEN) uses a block count with 8 bytes, according to section B.1.3 of the following document: https://www.etsi.org/deliver/etsi_ts/133400_133499/133401/14.05.00_60/ts_133401v140500p.pdf

The latter algorithm was added in release 0.53, and introduced issues in both AES_CNTR and AES_CNTR_BITLEN.

The issue is in the way this block count is being incremented in all implementations. For AES_CNTR, it should increment only 4 bytes, and for AES_CNTR_BITLEN, 8 bytes. In case of AVX, it was actually doing it the other way, incrementing 8 bytes for AES_CNTR and 4 bytes for AES_CNTR_BITLEN. In case of the other implementations, SSE and AVX512-VAES, AES_CNTR was correct, but AES_CNTR_BITLEN was not, since it was incrementing only 4 bytes.

It is worth noting that this issue has low risk, as it would only show up when there is an overflow in the block counter, which shouldn't happen unless the initial block count is not 0 or 1, but a very high number.

Bulat-Ziganshin commented 4 years ago

The way I solved similar problem is to increment f.e. only 4 bytes, and provide high-level wrappers that deal with wrapping over 0 for each particular standard. I.e. a wrapper just calls low-level function in smaller chunks with a block count until overflow point

pablodelara commented 4 years ago

Thanks @Bulat-Ziganshin ! We just solved the issue in the low-level functions, so I consider this issue closed. Let us know if you experienced this issue and this patch doesn't solve it completely.