Category: hashes

SCRAM: Salted Challenge Response Authentication Mechanism

SCRAM is an interesting proposal (RFC-5802) that aims to remove passwords being commonly sent across the wire. It does not appear to create additional requirements for certificates or shared secrets, so let’s see how it works.

The server is required to know the username in advance, but not the password, instead a hash of the password and a (per-user) salt and an iteration count which is used to create a challenge.

The client sends the username and a nonce. The server retrieves the salt and updates the iteration count and sends these back to the client as a challenge. The client hashes the password with the agreed upon hash function, and uses the salt and the iteration count in the calculation, and send it back to the server. The server is able to validate correctness of the hashed password with the information it has.  The server then sends back a hash which the client can check to validate the server.

There are several issues with it – the initial registration flow is left out, the requirements of the client and server to issue good nonces and maintain unique salts and iterations are high, and also the requirement for the server database itself to be secure – an exfiltration could enable brute force attacks.  Then it uses SHA-1 which is weak. The password is fixed and an update method would need to be designed for a full system.

Still it is interesting as a way to remove passwords being sent over the wire.

The protocol is used in XMPP as a standard mechanism for authentication.

 

SHA-3 Hash Construction

Keccak (or SHA-3, a ‘qualified successor’ to SHA-2) is a hash function based on interesting and novel ideas and claims to be post-quantum sufficient or quantum resistant.

Some Keccak sponge-hash-function pointers:

A sponge function is a generalization of both a) hash functions, which have a fixed output length, and b) stream ciphers (=state cipher), which have a fixed input length.

Random sponge = Random permutation

The spongeconstruction:

First, the input string is padded with a reversible padding rule and cut into blocks of r bits. Then the b bits of the state are initialized to zero and the sponge construction proceeds in two phases:

  • In the absorbing phase, the r-bit input blocks are XORed into the first r bits of the state, interleaved with applications of the function f, a fixed length permutation/transformation function function. When all input blocks are processed, the sponge construction switches to the squeezing phase.
  • In the squeezing phase, the first r bits of the state are returned as output blocks, interleaved with applications of the function f. The number of output blocks is chosen at will by the user.

The last c bits of the state are never directly affected by the input blocks and are never output during the squeezing phase.”

https://keccak.team/keccak_specs_summary.html

https://stackoverflow.com/questions/45158351/sha-3-in-python-implementation

https://stackoverflow.com/questions/43063282/qcryptographichash-what-is-sha3-here-in-reality

What security does Keccak offer against quantum attacks, specifically Grover’s algorithm?

“SHA-3 was designed to be very efficient in hardware but is relatively slow in software. SHA-3 takes about double the time compared to SHA-2 to run in software and about a quarter of the time to run in hardware.” This makes it less suitable than SHA-2 for key stretching, at least against an attacker that is hardware equipped.

The advantage of SHA-3 is that a computationally-simpler SHA-3(key | data) can suffice as a MAC.”