diff options
author | 2015-09-04 07:35:06 +0000 | |
---|---|---|
committer | 2015-09-04 07:35:06 +0000 | |
commit | ca6aa8198d2335f8c326c3dd4d26bf5899064214 (patch) | |
tree | 6274a2d971fc0cac0896efe8583927d0190e3d20 /moon-abe/pbc-0.5.14/doc/security.txt | |
parent | 92fd2dbfb672d7b2b1cdfd5dd5cf89f7716b3e12 (diff) | |
parent | 3baeb11a8fbcfcdbc31976d421f17b85503b3ecd (diff) |
Merge "init attribute-based encryption"
Diffstat (limited to 'moon-abe/pbc-0.5.14/doc/security.txt')
-rw-r--r-- | moon-abe/pbc-0.5.14/doc/security.txt | 45 |
1 files changed, 45 insertions, 0 deletions
diff --git a/moon-abe/pbc-0.5.14/doc/security.txt b/moon-abe/pbc-0.5.14/doc/security.txt new file mode 100644 index 00000000..c59cf4ba --- /dev/null +++ b/moon-abe/pbc-0.5.14/doc/security.txt @@ -0,0 +1,45 @@ +== 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. +____ |