gzz-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz-commits] manuscripts/Sigs article.rst


From: Tuomas J. Lukka
Subject: [Gzz-commits] manuscripts/Sigs article.rst
Date: Mon, 19 May 2003 16:54:16 -0400

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Tuomas J. Lukka <address@hidden>        03/05/19 16:54:16

Modified files:
        Sigs           : article.rst 

Log message:
        concl

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/Sigs/article.rst.diff?tr1=1.134&tr2=1.135&r1=text&r2=text

Patches:
Index: manuscripts/Sigs/article.rst
diff -u manuscripts/Sigs/article.rst:1.134 manuscripts/Sigs/article.rst:1.135
--- manuscripts/Sigs/article.rst:1.134  Mon May 19 16:40:43 2003
+++ manuscripts/Sigs/article.rst        Mon May 19 16:54:15 2003
@@ -340,57 +340,63 @@
 Conclusion
 ==========
 
-- presented a new signature scheme with several benefits
-  as far as we know not found together so far
+We have presented a new signature scheme with several benefits
+which, as far as we know, have not been embodied in the same
+algorithm so far.
+Our scheme uses
+no trapdoor funcs, so its security does not rely on 
+hardness of factoring or some other such problem.
+There is 
+no need for expiration of key or signature - keys don't
+degrade with use and cracking a signature seems to require
+a full search through the key space;
+there is also
+no state beyond the private key: there is no need to keep track
+of signed documents.
+The scheme is existentially
+unforgeable with an adaptive chosen message attack since a different
+private key produced by the random oracle
+is used to sign each message.
+
+We see the most significant application of our scheme
+in long-term digital publishing, 
+where the time limits and key management requirements
+of normal digital signatures
+are inconvenient.
+
+The downsides of the present scheme are that
+signatures are relatively large and signing
+and verifying require considerably more time
+than with other schemes. However, with modern
+computers storage space is cheap and the estimated
+signature times are not prohibitive. Additionally,
+considerable algorithmic improvements may be possible.
+
+Naturally, this scheme is not foolproof. Weaknesses in cryptographic
+hash functions may be found. Also, while
+all digital
+signatures in practice do depend on a hash function for
+long messages, our demands for are stricter: the hash
+function must also be a random oracle.
+
+The key idea of the scheme is to use 
+a deterministic random oracle
+to define a huge virtual tree of private keys,
+of which one path is traversed to find the private key to
+use to sign a particular document.
+
+We believe that as long as the random oracle, 
+used to generate the new private keys
+and to implement the one-time signatures, 
+isn't broken, an exhaustive
+key search is the only way to break the scheme.
+At the very least, this scheme is 
+not worse than RSA, where giving more signatures increases
+the possibility of factoring.
 
-  - no trapdoor funcs
-
-  - This scheme is existentially
-    unforgeable with an adaptive chosen message attack.
-
-  - no state beyond the private key: no need to keep track
-    of signed documents &c.
-
-  - no need for expiration of key or signature
-
-- application in long-term digital publishing, 
-  the time limits on normal digital signatures
-  are inconvenient
-
-- downsides 
-
-  - signatures relatively large and signing and
-    verifying relatively slow
-
-    - considerable improvements 
-      may be possible
-
-  - naturally not foolproof: e.g. hashes *do* get broken, REF
-
-  - signatures in practice do depend on a hash function for
-    long messages. however, it only needs to be collision-resistant,
-    not a random oracle
-
-- key idea: using the deterministic random oracle
-  to create a huge virtual tree of private keys,
-
-  - in one instance `$2^{160}$`, enough to have a separate private
-    key for each value to be signed.
-
-- also probabilistic, faster versions, which can be made
-  to work if only a predetermined number of documents is ever signed
-  with a key. 
-
-- we believe that as long as the random oracle, 
-  used to generate the new private keys
-  and to implement the one-time signatures, 
-  isn't broken, an exhaustive
-  key search is the only way to break the scheme.
-
-  - (however, we don't give full security analysis)
-
-  - not worse than RSA, where giving more signatures increases
-    the possibility of factoring
+.. However, a full security analysis
 
 Acknowledgments
 ===============
+
+




reply via email to

[Prev in Thread] Current Thread [Next in Thread]