Re: Strength of HMAC-SHA1-32

On 2008-11-18, Kristian Gjøsteen <kristiag+news@xxxxxxxxxxxx> wrote:
freeat12five <freeat12five@xxxxxxxxx> wrote:
That is indeed a great point. I think the real issue is in fact the
MAC tag length, but have started from the wrong end. We are not
concerned about encryption. It is an integrity and authentication

If you can have a sufficiently long key, a 32-bit HMAC-SHA1-32 will
ensure that the attacker can forge MAC tags with probability at most
2^(-32). If you can live with that forgery probability (few packets,
not so big a problem if a few packets are forged, etc.), then you
can probably live with HMAC-SHA1-32.

Also, with a 32-bit MAC, you should at least consider the possibility
of adding some form of automatic response to brute force attacks.

If, for example, the system alerts an operator whenever it receives
more than one bad packet per second over one hour, and stops accepting
data and shuts down gracefully as soon as the one-per-second threshold
is exceeded for the last six hours (thresholds pulled out of a hat),
it'll be rather hard for an attacker to carry out a brute force
attack: any attack slow enough to go undetected will take on average
136 years to succeed, whereas a fast packet flood attack only has a
0.0005% chance of succeeding before the system shuts down. (Of
course, the cost of the system shutting down should be weighed against
the cost of accepting a forged packet when setting the threshold.)

Obviously all this assumes that the operators, once alerted, are able
to do something useful to stop the attack. If the attacker can keep
throwing a continuous flood of forged packets at the system with
impunity, and there's nothing the operators can do except bring the
system back up and let the attacker try again, then you may still have
a problem.

Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.

Relevant Pages

  • [UNIX] Security Flaws Found in Tinc
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: ... This section describes how Tinc secures forwarded packets. ... The aim of encryption is to make the data unreadable for anybody who does ... It does not prevent an attacker from modifying the data. ...
  • Re: IPS Testing
    ... What if an attacker spoofs SQL Injection/XSS/CSRF ... payload within the packets that Nessus is sending. ... spoof every packets destined to their address ... buy it or download a solution FREE today! ...
  • Re: just an idea for packet protocol using ECB
    ... >> packets may be lost. ... the system would never shutdown if attackers kept ... The damage an attacker ... So each file transmission gets a session number. ...
  • Re: A new TCP/IP blind data injection technique?
    ... > True, but irrelevant to the problem at hand, where the attacker has neither ... some broken firewalls will strip the DF bit off packets. ... fragmentation of TCP packets happens in practice. ...
  • Re: just an idea for packet protocol using ECB
    ... > packets may be lost. ... During shutdown... ... The damage an attacker ... So each file transmission gets a session number. ...