Criticism of a proposed floating point (cs)prng requested.
in [Cryptography]
|
Prev: Criticism of a proposed stream cipher requested.
Next: Question about pass phrase cracking through brute force
From: Phoenix on 4 Jun 2010 10:20 On 4 Jun, 13:31, Maaartin <grajc...(a)seznam.cz> wrote: > The scaling itself is no problem. An integer PRNG works independently > of all the floating-point problems, the resulting real numbers may > differ slightly, but this mustn't play any role in e.g., simulation or > equation solving (if it did, the whole result would be garbage). For > crypto you need no floating-point at all. > > OTOH, using a floating-point based PRNG means that the generated > sequences may deviate substantially using different architectures, > compilers, and/or rounding modes. This should be no big problem for > non-cryptographic applications, but it makes it not exactly > repeatable. For crypto it's simply unusable. My question. IEEE 754-2008 is sufficient for all areas of science, except for crypto? Wend people needs accuracy for non-cryptographic applications, fp is not a problem. If I understand you, with crypto is another think?
From: MrD on 4 Jun 2010 10:48 Phoenix wrote: > On 4 Jun, 13:31, Maaartin <grajc...(a)seznam.cz> wrote: > >> The scaling itself is no problem. An integer PRNG works >> independently of all the floating-point problems, the resulting >> real numbers may differ slightly, but this mustn't play any role in >> e.g., simulation or equation solving (if it did, the whole result >> would be garbage). For crypto you need no floating-point at all. >> >> OTOH, using a floating-point based PRNG means that the generated >> sequences may deviate substantially using different architectures, >> compilers, and/or rounding modes. This should be no big problem for >> non-cryptographic applications, but it makes it not exactly >> repeatable. For crypto it's simply unusable. > > My question. > > IEEE 754-2008 is sufficient for all areas of science, except for > crypto? Floating-point representation is *not* sufficient for all areas of science. An FP number is only an approximation to a real number, and so FP is not suitable for problems requiring precise results. For crypto, results of computations must be accurate and repeatable in respect of every bit, otherwise the output will not be useable. FP doesn't give you that. I can imagine various (non-portable) cryptographic uses that could be made of floating-point hardware, but in general you have to use arbitrary-precision integers. -- MrD.
From: Mok-Kong Shen on 4 Jun 2010 11:06 Phoenix wrote: [snip] > IEEE 754-2008 is sufficient for all areas of science, except for > crypto? I have barely knowledge of that standard and of rounding issues but I surmise one practical issue for crypto applications is this: There are currently 32-bit and 64-bit hardware (of different architectures) in use. In crypto one needs to get from your FRAC results bit sequences (stored as integer variables). For full compatibility the sequences generated on different hardware have to be exactly the same. Have you checked that this is indeed ensured? M. K. Shen
From: Phoenix on 4 Jun 2010 11:21 On 4 Jun, 16:06, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote: > Phoenix wrote: > > [snip] > > > IEEE 754-2008 is sufficient for all areas of science, except for > > crypto? > > I have barely knowledge of that standard and of rounding issues but I > surmise one practical issue for crypto applications is this: There are > currently 32-bit and 64-bit hardware (of different architectures) in > use. In crypto one needs to get from your FRAC results bit sequences > (stored as integer variables). For full compatibility the sequences > generated on different hardware have to be exactly the same. Have you > checked that this is indeed ensured? > > M. K. Shen No.
From: Mok-Kong Shen on 4 Jun 2010 11:44
Phoenix wrote: > Mok-Kong Shen wrote: >> Phoenix wrote: >> >> [snip] >> >>> IEEE 754-2008 is sufficient for all areas of science, except for >>> crypto? >> >> I have barely knowledge of that standard and of rounding issues but I >> surmise one practical issue for crypto applications is this: There are >> currently 32-bit and 64-bit hardware (of different architectures) in >> use. In crypto one needs to get from your FRAC results bit sequences >> (stored as integer variables). For full compatibility the sequences >> generated on different hardware have to be exactly the same. Have you >> checked that this is indeed ensured? > No. Others may certainly have different opinions. I personally think though that constraining communication partners to use hardware that produce identical sequences isn't a too serious issue in many practical cases. If your scheme turns out to be superior in security (and maybe also processing efficiency) aspects, it would surely be a good contribution to cryto in my humble view. M. K. Shen |