3 ms·

HMAC interferes with my design goal of being simple and easily reproducing SHA1_Pass generated passwords on multiple platforms when needed. SHA1 was a design de

by 16s 16y ago

HMAC interferes with my design goal of being simple and easily reproducing SHA1_Pass generated passwords on multiple platforms when needed. SHA1 was a design decision to meet that goal. To carry out your attack, you would have to: 1. Somehow know the user used SHA1_Pass with full encodings and a consistent "sentence followed by salt" scheme. 2. Somehow trick the user to log onto your malicious site using a SHA1_Pass password (or gain access to the password in some other way). 3. Somehow produce a different hash that worked on a different site the user visits. All of that is possible in theory, but not likely to occur. SHA1_Pass generated passwords are not perfect, but they are not "wrong" either (or improper) as you seem to imply. The source is ISC licensed and available to you and others to edit. Feel free to do so. BTW: I think I know you from @misc.

JoachimSchipper 16y ago
> BTW: I think I know you from @misc. If you're talking about misc@openbsd.org, yes.
- 16s 16y ago
  Yes, OpenBSD misc. So for HMAC. I've looked at it more and I think your point is valid (even tho it's not very likely to occur). I may add it as an option. I don't really need to use it in the traditional sense (shared secret, integrity, etc) I only need it to better resist the length-extension attacks you point out. Can the key and the message be the same? I'd rather not prompt the user for a base sentence and a key/salt. But I can't find anyone using HMAC where the key and the msg are the same. I thought you might have some insight into this. Edit... here is a traditional HMAC (I think): echo -n msg | openssl dgst -sha1 -binary -hmac key | openssl enc -base64 Here is how I would need to use it without changing functionality: echo -n msg | openssl dgst -sha1 -binary -hmac msg | openssl enc -base64 I'm not sure this is proper from a cryptographic perspective.
  - 16s 16y ago
    I got advice from some guys on sci.crypto about how to potentially handle this. Some smart guys on that list. So I'll probably incorporate HMAC as an option for those who wish to use it.

by 16s 16y ago

JoachimSchipper 16y ago

> BTW: I think I know you from @misc. If you're talking about misc@openbsd.org, yes.

16s 16y ago
Yes, OpenBSD misc. So for HMAC. I've looked at it more and I think your point is valid (even tho it's not very likely to occur). I may add it as an option. I don't really need to use it in the traditional sense (shared secret, integrity, etc) I only need it to better resist the length-extension attacks you point out. Can the key and the message be the same? I'd rather not prompt the user for a base sentence and a key/salt. But I can't find anyone using HMAC where the key and the msg are the same. I thought you might have some insight into this. Edit... here is a traditional HMAC (I think): echo -n msg | openssl dgst -sha1 -binary -hmac key | openssl enc -base64 Here is how I would need to use it without changing functionality: echo -n msg | openssl dgst -sha1 -binary -hmac msg | openssl enc -base64 I'm not sure this is proper from a cryptographic perspective.
- 16s 16y ago
  I got advice from some guys on sci.crypto about how to potentially handle this. Some smart guys on that list. So I'll probably incorporate HMAC as an option for those who wish to use it.