Is this a secure key derivation function?
in [Cryptography]
|
Prev: CFP with Extended Deadline of Mar. 21, 2010: The 2010 International Conference on Internet Computing (ICOMP'10), USA, July 2010
Next: Server and Client Analogy – The NewCryptography Model
From: Joseph Ashwood on 21 Mar 2010 02:39 "Carsten Krueger" <cakruege(a)gmail.com> wrote in message news:yuilu3xv3irl.dlg(a)cakruege.my-fqdn.de... > Am Fri, 19 Mar 2010 20:55:16 -0700 schrieb Joseph Ashwood: >> You're incorrect again. The complexity of hash^10000 is the same as the >> complexity of hash^10000, > > ? Maybe if you left the comment I was responding to it would make more sense. >> You keep trying to justify the security, no amount of justification can >> change the truth, it is insecure. > > I don't like the implementation, too. > > My try was: Still far too complex, still the race condition, adds direct buffer overflow. The correct code looks like: Result=false saltbuffer = {canonical parsing of bytes} pwdbuffer = {canonical parsing of password} thash = {all zeros} for(iteration = 1 to MAX_ITERATIONS) thash = whirlpool(thash | pwdbuffer | saltbuffer) Key = thash Result=true Oddly things looks very similar to other designs, in particular it bears a striking resemblence to PKCS 5 and the password system used in UN*X variants. It also happens to not have any race conditions, lacks pointless complexity, doesn't have a buffer overflow problem (provided the two initial buffers are built correctly), doesn't have stack popping problems, etc. It really does help a great deal to actually pay attention to well written standards like the PKCS series. Joe
From: Noob on 22 Mar 2010 06:43 Joseph Ashwood wrote: > Still far too complex, still the race condition, adds > direct buffer overflow. I'm missing something. How can there be a race in single-threaded code? For my understanding, could you point out which entities are racing? and in what part of the code does this cause a problem? Regards.
From: Joseph Ashwood on 22 Mar 2010 09:56 "Noob" <root(a)127.0.0.1> wrote in message news:ho7hjj$e81$1(a)speranza.aioe.org... > Joseph Ashwood wrote: > >> Still far too complex, still the race condition, adds >> direct buffer overflow. > > I'm missing something. > > How can there be a race in single-threaded code? > > For my understanding, could you point out which entities > are racing? and in what part of the code does this cause > a problem? Its exploited in timing attacks. By setting the result to true before the computation there is a race condition. This kind of attack was popular in the late 90s, since then its been mostly removed from code in use. Joe
From: Phil Carmody on 24 Mar 2010 06:23
"Joseph Ashwood" <ashwood(a)msn.com> writes: > "Noob" <root(a)127.0.0.1> wrote in message > news:ho7hjj$e81$1(a)speranza.aioe.org... >> Joseph Ashwood wrote: >> >>> Still far too complex, still the race condition, adds >>> direct buffer overflow. >> >> I'm missing something. >> >> How can there be a race in single-threaded code? >> >> For my understanding, could you point out which entities >> are racing? and in what part of the code does this cause >> a problem? > > Its exploited in timing attacks. By setting the result to true before > the computation there is a race condition. No there isn't. And what do you mean by "setting the result"? Assigning a value to a local variable in no way "sets the result", only the return from the function actually sets the result. Can you not even see that a compiler is at liberty to _not even have_ that local variable, and simply have 2 different return paths returning constants? There is no race, you're on crack. > This kind of attack was > popular in the late 90s, since then its been mostly removed from code > in use. People have been removing *attacks* from code? Please engage brain before clicking 'send'. Phil -- I find the easiest thing to do is to k/f myself and just troll away -- David Melville on r.a.s.f1 |