# Questions about indexing a hash output to compose a final key

Recently I have watched the video Multi-Precision Arithmetic for Cryptology in C++, at Run-Time and at Compile-Time (at 21:56 seg) :

The speaker says that to use a byte from the user key as a subscript of an array allows side channel attacks. My question is what if to use this during a key crunching stage:

Do

HashOut = DoHash()

FinalKey += HashOut[currentKeyByte mod KeySize]

currentKeySize += 1

While (Len(FinalKey) < WantedSized);


Let's forget for a minute the widely known KDFs, okay? The idea behind the pseudo-code above would interfere in constant-time aspects?

If it does. What if to use the bytes from hashed key instead of the original bytes of the key?

The speaker says that to use a byte from the user key as a subscript of an array allows side channel attacks.

Using secret data (be it the user key, the actual secret key or internal key or secret-dependent data of the crypto routine) can, depending on what you're doing and what sort of access the attacker has to your machine while you're working with the key.

My question is what if to use this during a key crunching stage

FinalKey += HashOut[currentKeyByte mod KeySize]

It depends on what currentKeyByte is (your pseudocode doesn't specify it).

If it's an index that iterates between 0 and WantedSize in a predictable fashion, then that's not an issue. The attacker could potentially deduce information of what currentKeyByte is; on the other hand, if he knows that this is iteration 5, he already knows that currentKeyByte is 4, and so any further information he gets from the side channel doesn't tell him anything he doesn't already know. Now, if that's the case, then this code would wrap around if KeySize < WantedSize; that's might not be what you want to do, but that's an unrelated issue.

On the other hand, if currentKeyByte is, in fact, a byte from the user's password, well, yes, that can be an issue (if the attacker can plausibly run a program on the same computer while the above code is running); if I were you, I'd rethink this, and rework this code.

• Thanks poncho! The current key byte is a byte from the key. This byte picks one byte from the hashed output. The mod operation would be with hash output size, sorry for the mistake. So if I use the hash of the user's password I think it would solve the problem. Because it would always picks bytes from a buffer with a fixed size but with variable content. Would I thinking correctly? – Devel Jun 3 '19 at 20:20
• @Devel: one problem (of course) is that you'll be folding multiple bytes together; if KeySize == 32, then you'll be treating '!', 'A' and 'a' as the same character (and thus reducing password entropy). However, to answer you're question, yes, it might be potentially leaking some information (whether it actually does depends on how precisely the attacker would be able to measure the cache, as well as details on the cache line size (and how the HashOut buffer lines up against that) – poncho Jun 3 '19 at 20:50