summaryrefslogtreecommitdiffstats
path: root/moon-abe/pbc-0.5.14/doc/security.txt
diff options
context:
space:
mode:
authorRuan HE <ruan.he@orange.com>2015-09-04 07:35:06 +0000
committerGerrit Code Review <gerrit@172.30.200.206>2015-09-04 07:35:06 +0000
commitca6aa8198d2335f8c326c3dd4d26bf5899064214 (patch)
tree6274a2d971fc0cac0896efe8583927d0190e3d20 /moon-abe/pbc-0.5.14/doc/security.txt
parent92fd2dbfb672d7b2b1cdfd5dd5cf89f7716b3e12 (diff)
parent3baeb11a8fbcfcdbc31976d421f17b85503b3ecd (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.txt45
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.
+____