aboutsummaryrefslogtreecommitdiffstats
path: root/moon-abe/pbc-0.5.14/doc/security.txt
diff options
context:
space:
mode:
authorwukong <rebirthmonkey@gmail.com>2015-11-23 17:48:48 +0100
committerwukong <rebirthmonkey@gmail.com>2015-11-23 17:48:48 +0100
commitfca74d4bc3569506a6659880a89aa009dc11f552 (patch)
tree4cefd06af989608ea8ebd3bc6306889e2a1ad175 /moon-abe/pbc-0.5.14/doc/security.txt
parent840ac3ebca7af381132bf7e93c1e4c0430d6b16a (diff)
moon-abe cleanup
Change-Id: Ie1259856db03f0b9e80de3e967ec6bd1f03191b3
Diffstat (limited to 'moon-abe/pbc-0.5.14/doc/security.txt')
-rw-r--r--moon-abe/pbc-0.5.14/doc/security.txt45
1 files changed, 0 insertions, 45 deletions
diff --git a/moon-abe/pbc-0.5.14/doc/security.txt b/moon-abe/pbc-0.5.14/doc/security.txt
deleted file mode 100644
index c59cf4ba..00000000
--- a/moon-abe/pbc-0.5.14/doc/security.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-== 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.
-____