[Cryptography] Dumb Question about Pair-Wise Authentication

Marcus Brinkmann marcus.brinkmann at rub.de
Wed Apr 8 07:39:46 EDT 2020


Hi,

On 4/4/20 9:35 PM, Kent Borg wrote:
> When I want to send a message I do a hash of the message plus the
> secret, and append that hash. On receipt I strip the hash, do a new hash
> of the message plus the secret and compare the result. So simple. What
> is wrong with it? Seems radical.
> 
> There must even be a name for this.

You are looking for a message authentication code (MAC). Because you are
using a pre-shared secret, you are looking for a keyed MAC.  The scheme
you suggest is naive (in a technical sense, not meant derogatory), but
it is not terrible.  By using H(message || key) you avoid the
length-extension attack that is inherent in the alternative H(key ||
message). However, security depends on H(message) being collision-free,
as otherwise H(m1) == H(m2) implies H(m1 || key) == H(m2 || key).

The keyed MAC that virtually everybody is using is HMAC. It's a bit more
complicated than your idea, but not by much. You can find its definition
in RFC2104 or on Wikipedia (https://en.wikipedia.org/wiki/HMAC). Note
that for a conforming implementation, the secret is hashed before use if
it is longer than the hash size, but not if it is shorter or equal!
That's a trap for the young ones.

tl;dr: Use HMAC with pre-shared key for message authentication.

Postnote: If you have any other security goals apart from integrity
(i.e. protection against replay attachs, confidentiality, detection of
message loss, etc), everything gets much more complicated very quickly.
 It would then be much easier to use a sledgehammer solution like TLS,
SSH, some VPN, or, if asynchonous messaging is a must, some variation of
the Signal protocol, e.g. using the Noise framework).

> -kb, the Kent who is sensibly afraid of inventing security protocols.

Alrighty :)

-- 
Dipl.-Math. Marcus Brinkmann

Lehrstuhl für Netz- und Datensicherheit
Ruhr Universität Bochum
Universitätsstr. 150, Geb. ID 2/461
D-44780 Bochum

Telefon: +49 (0) 234 / 32-25030
http://www.nds.rub.de/chair/people/mbrinkmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x88B08D5A57B62140.asc
Type: application/pgp-keys
Size: 5925 bytes
Desc: not available
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200408/edb2a0b6/attachment.key>


More information about the cryptography mailing list