Commit Graph

9 Commits

Author SHA1 Message Date
Adam Langley
a59347eb4c RAND_set_rand_method takes a const parameter.
Change-Id: I37e7c00deeb74aa0b71ee0d3a242d33d4d413cf0
2015-06-24 17:02:15 -07:00
Matt Braithwaite
3e5e99d834 Dummy |RAND_set_rand_method|, |RAND_egd|, and |RAND_SSLeay|.
Change-Id: Ide555c77748b4ba8106f69b037e5ff78d81a56dc
Reviewed-on: https://boringssl-review.googlesource.com/5220
Reviewed-by: Adam Langley <agl@google.com>
2015-06-24 23:53:29 +00:00
Adam Langley
2cac3506fa Handle RDRAND failures.
I mistakenly believed that only RDSEED could fail. However, the Intel
manuals state that RDRAND can fail too.

I can't actually observe it failing, even with all cores running RDRAND in a
tight loop. In any case, the ChaCha20 masking means that it wouldn't be
a big deal anyway.

Still, this change tests the carry flag after RDRAND and the code falls
back to |CRYPTO_sysrand| if RDRAND has a hiccup. (The Intel manuals
suggest[1] calling RDRAND in a loop, ten times, before considering it to
have failed. But a single failure appears to be such a rare event that
the complexity in the asm code doesn't seem worth it.)

This change also adds an asm function to fill a buffer with random data.
Otherwise the overhead of calling |CRYPTO_rdrand|, and bouncing the data
in and out of memory starts to add up.

Thanks to W. Mark Kubacki, who may have reported this. (There's some
confusion in the bug report.)

Before:

Did 6148000 RNG (16 bytes) operations in 1000080us: 98.4 MB/s
Did 649000 RNG (256 bytes) operations in 1000281us: 166.1 MB/s
Did 22000 RNG (8192 bytes) operations in 1033538us: 174.4 MB/s

After:

Did 6573000 RNG (16 bytes) operations in 1000002us: 105.2 MB/s
Did 693000 RNG (256 bytes) operations in 1000127us: 177.4 MB/s
Did 24000 RNG (8192 bytes) operations in 1028466us: 191.2 MB/s

[1] Intel Reference Manual, section 7.3.17.1.

Change-Id: Iba7f82e844ebacef535472a31f2dd749aad1190a
Reviewed-on: https://boringssl-review.googlesource.com/5180
Reviewed-by: Adam Langley <agl@google.com>
2015-06-23 20:56:33 +00:00
David Benjamin
81091d55e1 Don't use uninitialized memory in RAND_bytes.
We can't actually catch this with MSan because it requires all code be
instrumented, so it needs a NO_ASM build which no disables that code. valgrind
doesn't notice either, possibly because there's some computation being done on
it. Still, we shouldn't use uninitialized memory.

Also get us closer to being instrumentable by MSan, but the runner tests will
need to build against an instrumented STL and I haven't tried that yet.

Change-Id: I2d65697a3269b5b022899f361730a85c51ecaa12
Reviewed-on: https://boringssl-review.googlesource.com/4760
Reviewed-by: Adam Langley <agl@google.com>
2015-05-15 20:31:27 +00:00
Matt Braithwaite
af3d5bd5a4 Add no-op |RAND_load_file| function for compatibility.
Change-Id: I9493a1509a75d3f0d99ce2b699d8781ad9b1bafa
Reviewed-on: https://boringssl-review.googlesource.com/4540
Reviewed-by: Adam Langley <agl@google.com>
2015-05-12 00:36:11 +00:00
Brian Smith
3700778248 Fix Windows build failures caused by 310d4dd.
MSVC doesn't like |const size_t len| in a function definition where the
declaration was just |size_t len| without the |const|. Also, MSVC needs
declarations of parameterless functions to have a |void| parameter list.

Change-Id: I91e01a12aca657b2ee1d653926f09cc52da2faed
Reviewed-on: https://boringssl-review.googlesource.com/4329
Reviewed-by: Adam Langley <agl@google.com>
2015-04-15 03:06:29 +00:00
Adam Langley
c3ef76f327 Compatibility changes for wpa_supplicant and OpenSSH.
OpenSSH, especially, does some terrible things that mean that it needs
the EVP_CIPHER structure to be exposed ☹. Damian is open to a better API
to replace this, but only if OpenSSL agree too. Either way, it won't be
happening soon.

Change-Id: I393b7a6af6694d4d2fe9ebcccd40286eff4029bd
Reviewed-on: https://boringssl-review.googlesource.com/4330
Reviewed-by: Adam Langley <agl@google.com>
2015-04-14 20:18:28 +00:00
Adam Langley
310d4dd6b6 rand: new-style locking and support rdrand.
Pure /dev/urandom, no buffering (previous behaviour):
Did 2320000 RNG (16 bytes) operations in 3000082us (773312.2 ops/sec): 12.4 MB/s
Did 209000 RNG (256 bytes) operations in 3011984us (69389.5 ops/sec): 17.8 MB/s
Did 6851 RNG (8192 bytes) operations in 3052027us (2244.7 ops/sec): 18.4 MB/s

Pure rdrand speed:
Did 34930500 RNG (16 bytes) operations in 3000021us (11643418.5 ops/sec): 186.3 MB/s
Did 2444000 RNG (256 bytes) operations in 3000164us (814622.1 ops/sec): 208.5 MB/s
Did 80000 RNG (8192 bytes) operations in 3020968us (26481.6 ops/sec): 216.9 MB/s

rdrand + ChaCha (as in this change):
Did 19498000 RNG (16 bytes) operations in 3000086us (6499147.0 ops/sec): 104.0 MB/s
Did 1964000 RNG (256 bytes) operations in 3000566us (654543.2 ops/sec): 167.6 MB/s
Did 62000 RNG (8192 bytes) operations in 3034090us (20434.5 ops/sec): 167.4 MB/s

Change-Id: Ie17045650cfe75858e4498ac28dbc4dcf8338376
Reviewed-on: https://boringssl-review.googlesource.com/4328
Reviewed-by: Adam Langley <agl@google.com>
2015-04-14 20:13:42 +00:00
Adam Langley
95c29f3cd1 Inital import.
Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta).

(This change contains substantial changes from the original and
effectively starts a new history.)
2014-06-20 13:17:32 -07:00