HN Simulatornew | past | comments | lists | submit | pbsd's commentslogin

That is mentioned in a years old post: https://saweis.net/posts/nist-curve-seed-origins.html

Off your direct point, but I found this line in the article interesting: ""Jerry Solinas did provide the seeds to me sometime in Fall 1997."

The seed for P-224 uses a timestamp from 1998, and they also said the four binary curve seeds were timestamps from 1984 that were doubled - someone did srand48(time / 2) not srand48(time).

Did the P-224 seed get updated later / was not provided in 1997, or is there some other reason for this? Otherwise, it looks like one third of these values need additional excuses to get them to map to the time range in question...


The first version of the X9.62-1998 standard, where these curves first showed up, only had P-192, P-256, and the prime192v{1,2,3} and prime239v{1,2,3} curves. These also happen to be the curves with the earliest timestamps (along with P-384 and P-521). It also contained 163-bit curves, but none of those correspond to the later B-163 curve.

So yeah, it seems plausible P-224 and the B-* curves were generated at a later date.


An old version of binutils [1] explains what DDS means:

    How to encode VEX.vvvv:
    0: VEX.vvvv must be 1111b.
    1: VEX.NDS.  Register-only source is encoded in VEX.vvvv where
       the content of source registers will be preserved.
       VEX.DDS.  The second register operand is encoded in VEX.vvvv
       where the content of first source register will be overwritten
       by the result.
       VEX.NDD2.  The second destination register operand is encoded in
       VEX.vvvv for instructions with 2 destination register operands.
       For assembler, there are no difference between VEX.NDS, VEX.DDS
       and VEX.NDD2.
    2. VEX.NDD.  Register destination is encoded in VEX.vvvv for
    instructions with 1 destination register operand.
    3. VEX.LWP.  Register destination is encoded in VEX.vvvv and one
       of the operands can access a memory location.
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;...

The cycle count for RDTSC is ~25 cycles on Skylake-era microarchitectures. The 49 number shown in the OP seems off.


It's actually benchmarking 1000 repetitions of the RDTSC instruction running in parallel.

My guess... On Skylake, multiple in-flight RDTSC instructions slow each other down for some reason?

Possibly because it's attempting to provide a strict monotonic guarantee, that no two RSTSC instructions will return the same timestamp. Intel's manual only claims monotonic, which theoretically allows for two RSTSC instructions to return the same timestamp.


Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: