Repository navigation
Range Check Exception when using KDF with empty password #76
Description
In my app, I noticed a "Range Check Exception" when the user didn't enter a password (which I clearly forgot to check), and therefore the, empty password was tried to be processed through KDF. The reason for the Range Check Exception is that Data[0] is accessed, which does not exist if Data is empty.
class function TDECHashAuthentication.KDFx(const Data, Seed: TBytes;
MaskSize: Integer;
Index: UInt32 = 1): TBytes;
begin
if (length(Seed) > 0) then
Result := KDFx(Data[0], Length(Data), Seed[0], Length(Seed), MaskSize, Index)
else
Result := KDFx(Data[0], Length(Data), NullStr, Length(Seed), MaskSize, Index)
end;
(This is just an example. Not only KDFx is affected. Other methods are affected too.)
It is dangerous that a method can fail this way, especially because "range check" can be disabled in the compiler settings for performance reasons.
In my opinion we should do the following: Find out (from official sources / reference implementation) what KDF123x/PBKDF/MGF1 is supposed to do if the input is 0 bytes. Is it supposed to fail, or is it supposed to return a key "X"?
- If it shall output a key "X", then we should implement it this way
- If it is supposed to fail, then we must throw an Exception instead of risking a memory-corruption if range checks are disabled
(edit: typo. of course I meant "instead of risking")
Activity
MHumm commentedon May 12, 2024
I found one first source, which is linked in this stack overflow discussion (std6.pdf). See p. 21 and following in the PDF.
https://crypto.stackexchange.com/questions/67280/formal-description-of-kdf1-and-kdf2
But: it doesn't specify what to do if the input length is 0.
Quote:
A key derivation function is a function KDF(x, l) that takes as input an octet string x and
an integer l >= 0, and outputs an octet string of length l. The string x is of arbitrary length,
although an implementation may define a (very large) maximum length for x and maximum size
for l, and fail if these bounds are exceeded.
MHumm commentedon May 12, 2024
Further ressearch shows, that the real specification ight be in IEEE P1363, which is a withdrawn standard from IEEE for which the specification is behind a pay wall.
MHumm commentedon Jan 19, 2025
Is there anybody with access to IEEE P1363?
MHumm commentedon Jan 20, 2025
Somebody provided me some documents (after I requested the IEEE P1363 spect. in another forum). I need to find the time to read them. I hope they contain information about that case.