5 ms·

I'm not sure I follow your argument. The user would provide a plain SHA1 hash (or half of one) as their password (either hex or b64 encoded). How do you plan to

by 16s 16y ago

I'm not sure I follow your argument. The user would provide a plain SHA1 hash (or half of one) as their password (either hex or b64 encoded). How do you plan to get the sentence out of that hash? You have no idea what the underlying sentence is. What am I missing... could you elaborate? Edit: I think I understand what you are getting at now... what you suggest would require the use of a fully encoded SHA1_Pass generated password (not halves) and the user would have to be using a "sentence + salt" scheme where the sentence always stays the same in order for this to work in real life, right? Also, there are many other ways to use SHA1_Pass where your proposed attack would not work at all. What if they put the salt someplace in the middle? Or used entirely different sentences for different sites? How would you know?

JoachimSchipper 16y ago
Your edit is basically correct, but note that moving the salt doesn't help all that much (see http://news.ycombinator.com/item?id=2432014 http://news.ycombinator.com/item?id=2432014). It's not hard to imagine some practical difficulties for an attacker. But if you're writing this kind of software, you should get it right.
- 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

Your edit is basically correct, but note that moving the salt doesn't help all that much (see http://news.ycombinator.com/item?id=2432014 http://news.ycombinator.com/item?id=2432014). It's not hard to imagine some practical difficulties for an attacker. But if you're writing this kind of software, you should get it right.

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.