0

First note: This is on-disk usage only, never transmitted over a server.

How secure, or additionally secure, is it to sha-3 (512) a password if said password is below 128 characters, THEN proceeding to scrypt it?

Is it more secure than straight scrypting the password? Should beyond 128 be sha-3'd? Should there even be any sha-3ing of it at all?

I'm aware sha-3 is just a hashing and not the same as aes/bcrypt/scrypt/twofish etc., I am merely looking to see if some sort of addition layer can be added for even more security than scrypt offers by default.

On a note of weak password will always be weak, in this instance a file can be specified as the password (of any size within the operational limits of scrypt), but a regular password can be used as well, therefore my question arises:

How much more secure, even in a theoretical sense, if it all, is sha3-512-ing a password below 128 characters, and above 128 characters, before scrypt-ing it?

Robert 'Jet' Rowe
  • 101
  • It could leak whether or not the hashed password was longer/shorter then your threshold based on how long the computation takes. Can we ask why sha-3 should be applied at all? As in, why do you expect this would improve security? – Ella Rose Aug 14 '16 at 02:32
  • Because 128 character length is better than 127 character length, and not knowing necessarily whether a user used a sha3-hashed string to create the scrypt result can also make it more difficult for that route of attack. – Robert 'Jet' Rowe Aug 14 '16 at 02:35
  • "How much more secure, even in a theoretical sense": zero. The answer is zero. It does not make it more secure. One sha-3 calculation before scrypt is like wearing your lucky hat...AND a bulletproof vest, before your best "watch this" moment yet. – Ben Aug 14 '16 at 04:03
  • 1
    This exact same idea was asked over at the Cryptography Stack Exchange not too long ago, and I'd highlight [my answer to it](http://crypto.stackexchange.com/questions/36864/can-you-use-a-hash-as-a-password/36867#36867). – Luis Casillas Aug 14 '16 at 04:25
  • bcrypt can't handle 128 chars in a pw, can scrypt? if not, then you are making the attack easier. – dandavis Aug 14 '16 at 21:26

1 Answers1

2

An attacker would not guess the 128 long character that goes into scrypt, they would simply guess the 127 character long password that goes into sha-3. This might not seem like a problem if the password is 127 characters long, but it's arguable that scrypt is needed in such a situation to begin with.

Using realistic measures of password length, i.e. 5-10, this discrepancy becomes larger - the adversaries work factor will be limited by the length of the actual password, not the length of the output of the sha-3 hash.

Doing this may leak whether or not the length of the password is greater or less then your threshold, due to the operation requiring variable lengths of time.

So there should not be any sha-3'ing of anything at all. Remember: adding more crypto doesn't solve the problem magically, and doing things that are not explicitly beneficial can only increase your attack surface.

Ella Rose
  • 293
  • 2
  • 10
  • I see you have a note that says nothing is being transmitted to a server; That makes me question why you even need scrypt at all, unless you're using it as a key derivation function for deriving a key from a password. – Ella Rose Aug 14 '16 at 02:48
  • Given that an attack would not know whether the password has sha3 applied before-hand, meaning the potential base password could still be anywhere between 1 and the operational limit of scrypt, does that change your opinion? – Robert 'Jet' Rowe Aug 14 '16 at 03:06
  • And the attacker won't know about the sha-3 because...? – Ben Aug 14 '16 at 16:40