1

I’m wondering how often a terminal needs to perform a cryptographic hash (ex: SHA) throughout the lifetime of an IPSEC session where both ends are authenticated using certificates. From what I can gather and from a client perspective:

  • A client connects to a server, fetches its certificate and performs an asymmetric encryption function (ex: RSA) and SHA to validate the certificate’s signature

  • The client and server perform Diffie-Hellman to agree on a symmetric key what will be good for hours using each other’s public keys where I would a assume they use RSA and SHA functions 4 more times

  • Both carry one for hours using strictly AES and the symmetric key to encrypt the payload which integrity can be checked within the payload using a simple CRC. Not all packets are signed (otherwise RSA would be required every time and Diffie-Hellman would be pointless).

So my assumption would be that RSA and SHA are used fives time only at connection and possibly four times each time the symmetric key is renewed (typically every 24 hours, although I assume that the previously established tunnel could be used to renew the symmetric key). Is this correct? I was told we can’t use SHA-2 on a platform due to the lack of support of the cryptographic accelerator. Thanks.

|improve this question
2

which integrity can be checked within the payload using a simple CRC

Not a simple CRC. Classic IPsec cipher suites usually use HMACs based on cryptographic hash functions (e.g. SHA-1/2) so verifying and creating Integrity Check Values (ICV) for every ESP packet will require several applications of the negotiated hash function. However, there are alternative integrity algorithms based on encryption algorithms (e.g. AES-XCBC-96) if you wanted to avoid the use of hash functions (or have hardware acceleration for AES). And there are, of course, combined-mode ciphers (aka AEAD) e.g. AES-GCM, which generate/verify ICVs while encrypting/decrypting the packet in one pass.

|improve this answer
  • Thanks, Indeed I overlooked HMACs. I assume that verifying a HMAC is less computationally intensive than de-crypting the payload (which we have to do at some point) and verifying a checksum (only somebody with the private key could build such payload). The reason why we use HMAC instead is to mitigate DDOS attacks? – Louis Feb 1 '18 at 0:38
  • @Louis An HMAC is not necessarily less computationally intensive. The hashing speed of a hash and the encryption/decryption speed of a cipher are often quite similar. Also, some types of HMAC implementations require decrypting before hashing. The Encrypt-Then-MAC construction first encrypts the payload, then MACs it. The MAC-Then-Encrypt construction first MACs the plaintext, then encrypts it, so verifying the payload requires decrypting it and running a hash over it. Not to mention, it's easier to optimize ciphers than hashes (cached round keys, etc). HMACs are fast, but not that fast. – forest Feb 1 '18 at 3:20
  • @Louis HMAC is not designed to mitigate DoS. They're designed to address the issue of ciphertext malleability, where an attacker that doesn't know the key may be able to modify the ciphertext such that it will decrypt into plaintext in predictable ways. An HMAC allows the endpoint to know for sure that only a party with access to the encryption key will be able to create or modify a valid HMACed payload. – forest Feb 1 '18 at 3:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.