[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56422.1396438686@critter.freebsd.dk>
Date: Wed, 02 Apr 2014 11:38:06 +0000
From: "Poul-Henning Kamp" <phk@....freebsd.dk>
To: discussions@...sword-hashing.net, Solar Designer <solar@...nwall.com>
cc: Brandon Enright <bmenrigh@...ndonenright.net>
Subject: Re: [PHC] A little nit which bothers me...
In message <20140402082306.GA24793@...nwall.com>, Solar Designer writes:
>Data-dependent branching has not been used as much yet, [...]
I never saw the point really.
First, the construct needs to be symmetic in order to not leak
too much timing information:
if (CONDITION(entropy)) {
entropy = FUNC1(entropy);
discard = FUNC2(entropy);
} else {
discard = FUNC1(entropy);
entropy = FUNC2(entropy);
}
But there are so much junk between the CPU and the memory these
days that I still expect timing attacks can demask the condition bit.
The way to solve that is to only condition data-dependent
branching on "dead-end bits" which don't lead back to our entropy:
if (CONDITION(HASH(entropy || "Lorem ipsum dolor sit..."))) {
entropy = FUNC1(entropy);
discard = FUNC2(entropy);
} else {
discard = FUNC1(entropy);
entropy = FUNC2(entropy);
}
We cannot lower our standards and allow timing attacks against
"dead-end" bits:
if (CONDITION(HASH(entropy || "Lorem ipsum dolor sit..."))) {
entropy = FUNC1(entropy);
} else {
entropy = FUNC2(entropy);
}
That would give a 50% discount on a brute-force attack with timing
information.
In brute-force attack without timing information, the "discard"
bits could obviously be optimised out, that's also no good, so lets
not discard those bits anyway:
if (CONDITION(HASH(entropy || "Lorem ipsum dolor sit..."))) {
entropy[first_half] = FUNC1(entropy);
entropy[second_half] = FUNC2(entropy);
} else {
entropy[second_half] = FUNC1(entropy);
entropy[first_half] = FUNC2(entropy);
}
And then it follows trivially that this is the same as:
i = CONDITION(HASH(entropy || "Lorem ipsum dolor sit..."))
entropy = FUNC12(entropy);
if (i)
swap_first_and_second_half(entropy)
Ohh well...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@...eBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Powered by blists - more mailing lists