[Top][All Lists]
[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
===============
+
+
- [Gzz-commits] manuscripts/Sigs article.rst, (continued)
- [Gzz-commits] manuscripts/Sigs article.rst, Tuomas J. Lukka, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Tuomas J. Lukka, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Tuomas J. Lukka, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Benja Fallenstein, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Tuomas J. Lukka, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Benja Fallenstein, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Benja Fallenstein, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Tuomas J. Lukka, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Benja Fallenstein, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Tuomas J. Lukka, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst,
Tuomas J. Lukka <=
- [Gzz-commits] manuscripts/Sigs article.rst, Tuomas J. Lukka, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Tuomas J. Lukka, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Tuomas J. Lukka, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Tuomas J. Lukka, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Tuomas J. Lukka, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Tuomas J. Lukka, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Benja Fallenstein, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Tuomas J. Lukka, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Benja Fallenstein, 2003/05/19
- [Gzz-commits] manuscripts/Sigs article.rst, Benja Fallenstein, 2003/05/19