summaryrefslogtreecommitdiffstats
path: root/src/vppinfra/tw_timer_16t_2w_512sl.c
diff options
context:
space:
mode:
authorBenoît Ganne <bganne@cisco.com>2022-01-18 15:56:41 +0100
committerBeno�t Ganne <bganne@cisco.com>2023-03-23 08:59:31 +0000
commit5527a78ed96043d2c26e3271066c50b44dd7fc0b (patch)
tree3e4186cb439e10051d013cc71c1f7d8d81ad9613 /src/vppinfra/tw_timer_16t_2w_512sl.c
parentad95b06181c354291f4433c5e550cb89c5122252 (diff)
ipsec: make pre-shared keys harder to misuse
Using pre-shared keys is usually a bad idea, one should use eg. IKEv2 instead, but one does not always have the choice. For AES-CBC, the IV must be unpredictable (see NIST SP800-38a Appendix C) whereas for AES-CTR or AES-GCM, the IV should never be reused with the same key material (see NIST SP800-38a Appendix B and NIST SP800-38d section 8). If one uses pre-shared keys and VPP is restarted, the IV counter restarts at 0 and the same IVs are generated with the same pre-shared keys materials. To fix those issues we follow the recommendation from NIST SP800-38a and NIST SP800-38d: - we use a PRNG (not cryptographically secured) to generate IVs to avoid generating the same IV sequence between VPP restarts. The PRNG is chosen so that there is a low chance of generating the same sequence - for AES-CBC, the generated IV is encrypted as part of the message. This makes the (predictable) PRNG-generated IV unpredictable as it is encrypted with the secret key - for AES-CTR and GCM, we use the IV as-is as predictable IVs are fine Most of the changes in this patch are caused by the need to shoehorn an additional state of 2 u64 for the PRNG in the 1st cacheline of the SA object. Type: improvement Change-Id: I2af89c21ae4b2c4c33dd21aeffcfb79c13c9d84c Signed-off-by: Benoît Ganne <bganne@cisco.com>
Diffstat (limited to 'src/vppinfra/tw_timer_16t_2w_512sl.c')
0 files changed, 0 insertions, 0 deletions