7

My Question(s)

I am wondering if I have a password (long enough) and I cypher it by itself (let's ignore the salt) in this way:

cy_hash(mypassword)=cypher(text=mypassword,key=mypassword)

Then, is cy_hash as secure as md5, sha1, sha512, etc?

Also:

  • Is there any theoretical comparison between these methods?
  • Has this method ever been used in practice? If not, why?
  • Is there any research on this hash?

My research efforts

As for my research efforts, I have looked around and found the following Q&As:

but those Q&As do not answer my question. You can safely skip linking to them.

e-sushi
  • 17,891
  • 12
  • 83
  • 229
edwardo
  • 73
  • 1
  • 3
  • 4
    A hash functions also have a input size that varies for a fixed output size. This is not the case for a cipher. – Biv May 28 '17 at 09:46
  • 8
    A key has a fixed size, a password a variable size. So how is this even supposed to work? – CodesInChaos May 28 '17 at 09:49
  • Basically you could also just encrypt any string (12345blabla) with the password and when the password is given, try to decrypt it and check that there is no error, i.e. the string is returned.

    I think the big problems here are that it is more difficult to implement than a "simple" hash and that it is way too fast. A password hash should be slow, whereas encryption algorithms are usually designed to be fast, sometimes even supported by hardware acceleration (AES).

     – rugk May 28 '17 at 13:34
  • 1
    Thinking of this idea: this scheme is probably also vulnerable because of the birthday paradox: if the output is too small then it may become possible to birthday attack on a database with stored hashes. This would particularly the case for weaker passwords and a badly chosen encryption scheme. Not that we needed yet another reason :) – Maarten Bodewes May 28 '17 at 13:46
  • More importantly, what are the weaknesses of current state-of-the-art password hashes (argon2, scrypt, bcrypt) that you are seeking to mitigate, and why do you think your solution mitigates them? You seem to be approaching cryptography from the wrong direction: you're inventing solutions without having a problem you wish to solve in the first place. – Stephen Touset May 28 '17 at 23:19
  • Almost a duplicate: Turning a cipher into a hashing function – tylo May 29 '17 at 08:15
  • For extra security, choose one-time pad as the encryption algorithm. You'll find you're not very collision-resistant. – Ulrich Schwarz May 29 '17 at 12:49

3 Answers3

19

There is an important misconception on your part: in general cryptographic hashes such as MD5, SHA-1 or SHA-512 should not be used to directly hash a password. A password hash or PBKDF should be used. Examples are PBKDF2, bcrypt, scrypt and Argon2. These functions also take a salt and work factor to provide additional protection.

There are a few problems with your idea:

  1. as noted in the comments, a cipher generally takes a key with one or more specific, pre-defined sizes;
  2. a cipher would output a size as large or larger than the input which would leak the password size (and require VARBINARY in databases, larger buffer allocation etc.);
  3. it is missing additional parameters such as a salt or iteration count to make it a password hash;
  4. it would have almost the same performance as just hashing the password (it would offer no advantages, in other words).

No, there is likely little to no research as it would be dismissed out of hand. There was however a password hash competition quite recently where it could have been entered (and immediately dismissed).

Note that MD5 and SHA-1 have been broken and should generally not be used anymore.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
  • Thank you very much. I assume that the salt is given and we no longer think about it (salt+pass used for both text and key). Salt can be used to fix the length as well. For weak passwords, it does not matter either you use cy_hash or md5. Both are weak for weak passwords. It can be iterated. Why not? Thus I disagree with points 1,3 – edwardo May 28 '17 at 11:03
  • Adding a salt does not dismiss point 1. The concern is that the cipher output will always be at least the first integer multiple of the block size of the cipher larger than the salt + password. Unless you place an upper bound on the size of the user's password (and you should not!), you have not uniform upper bound to pad the salt + password up to. – Lukasa May 28 '17 at 11:55
  • 5
    More importantly though, if you allow a password longer than the key size (e.g. for AES-256 any password more than 32 ASCII chars long) then you need to use a key-derivation-function to shrink the password down anyway. At this point, you may as well skip the cipher step and just use PBKDF2 (a key-derivation function) directly! – Lukasa May 28 '17 at 11:56
  • 2
    Please don't call MD5 a "secure hash". It's fundamentally broken! – rugk May 28 '17 at 13:19
  • 1
    @rugk It was more a family designation than a recommendation - I added a warning about MD5 and SHA-1 below my answer, although they are funnily enough still OK for this kind of use. – Maarten Bodewes May 28 '17 at 13:40
  • 2
    Perhaps call it a cryptographic hash instead? – user253751 May 28 '17 at 22:34
  • I can live with that - and I already changed the answer accordingly. – Maarten Bodewes May 28 '17 at 22:37
4

No, it is not. The function of a hash is to have an irreversible function. The function of a salt is to prevent rainbow tables.

If you use you approach on a large user DB, and this DB gets out (bad enough in the salted case), people can use a rainbow table to get valid login information to your system with high probability.

Sascha
  • 148
  • 3
1

Of course it depends on the choice of cypher(), but in general, no, it's not secure. Here are some of the problems with your scheme:

  • It's too fast. We want a password hash to be slow, so offline dictionary search will take a long time. Password hashing schemes are designed to be slow (with a tuning knob that lets you control exactly how slow). For typical encryption methods, your scheme isn't slow; it'll be too fast, and that's actually a bug, not a feature.

  • Artificial length limits on the password. Your scheme doesn't allow arbitrary-length passwords; the length of the password is limited by the length of the cypher() encryption algorithm. For instance, AES128 takes a 16-byte key. That means that your scheme couldn't accept passwords longer than 16 bytes, if we used AES128 encryption as cypher(). That's generally a bad idea -- artificial restrictions on the length of the password can only harm security.

  • Not deterministic. We need password hashing to be deterministic: hash the same password twice, and we need to get the same answer both times. Most modern secure encryption algorithms are randomized (for IND-CPA security). For instance, they might use a random IV. That will be no good when we use it with your scheme. This is fixable, by eliminating all the randomness and replacing it with fixed values, but it requires modifications before we can apply your scheme.

There are other problems, like lack of a good way to provide a salt.

Overall, it means that your scheme has significant disadvantages that standard methods don't have; and it doesn't have any compensating advantages that would outweigh its disadvantages.

D.W.
  • 36,365
  • 13
  • 102
  • 187