PBC Library Manual 0.5.11 - Stanford Crypto Group

Chapter 9. Security issues
Potential problems for the paranoid.
Truncated hashes
For points on an elliptic curve over the base field, element_from_hash() will truncate the input hash
until it can represent an x-coordinate in that field. (PBC then computes a corresponding y-coordinate.)
Ideally the hash length should be smaller than size of the base field and also the size of the elliptic curve
group.
Hashing to elements in field extensions does not take advantage of the fact that the extension has more
elements than the base field. I intend to rewrite the code so that for a degree n extension code, PBC splits
the hash into n parts and determine each polynomial coefficient from one ofthe pieces. At the moment
every coefficient is the same and depends on the whole hash.
This is harmless for the base field, because all the pairing types implemented so far use an integer mod
ring as the base field, rather than an extension of some low characteristic field.
Zeroed memory
Unlike OpenSSL, there are no functions to zero memory locations used in sensitive computations. To
some extent, one can use element_random() to overwrite data.
PRNG determinism
On platforms without /dev/urandom PBC falls back on a deterministic pseudo-random number
generator, except on Windows where it attempts to use the Microsoft Crypto API.
Also, /dev/urandom differs from /dev/random. A quote from its manpage:
A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not
sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack
on the algorithms used by the driver. Knowledge of how to do this is not available in the current non-classified
literature, but it is theoretically possible that such an attack may exist. If this is a concern in your application,
use /dev/random instead.
45