Perché HMAC è troncato in IPsec?

1

Sto osservando lo standard IPsec e mi sono reso conto che il controllo dell'integrità e dell'autenticazione dei dati si basa sulla versione troncata a 96 bit degli algoritmi HMAC. Ad esempio, in IPsec v3 possiamo usare HMAC-MD5-96, HMAC-SHA-1-96, AES-XCBC-MAC-96. Qual è la ragione di questa scelta?

    
posta sergionsk8 06.02.2016 - 18:14
fonte

1 risposta

1

Per la risposta a questo check out RFC 2104 , emineine:

A well-known practice with message authentication codes is to
truncate the output of the MAC and output only part of the bits
(e.g., [MM, ANSI]). Preneel and van Oorschot [PV] show some
analytical advantages of truncating the output of hash-based MAC
functions. The results in this area are not absolute as for the
overall security advantages of truncation. It has advantages (less
information on the hash result available to an attacker)
and
disadvantages (less bits to predict for the attacker). Applications
of HMAC can choose to truncate the output of HMAC by outputting the t leftmost bits of the HMAC computation for some parameter t (namely,
the computation is carried in the normal way as defined in section 2
above but the end result is truncated to t bits). We recommend that
the output length t be not less than half the length of the hash
output (to match the birthday attack bound) and not less than 80 bits (a suitable lower bound on the number of bits that need to be
predicted by an attacker). We propose denoting a realization of HMAC that uses a hash function H with t bits of output as HMAC-H-t. For
example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function
and with the output truncated to 80 bits. (If the parameter t is not specified, e.g. HMAC-MD5, then it is assumed that all the bits of the hash are output.)

Il troncamento riduce anche la quantità di dati trasmessi sul filo, riducendo così i requisiti di larghezza di banda.

    
risposta data 08.02.2016 - 10:34
fonte

Leggi altre domande sui tag