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 15:02:05 -0400

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

Modified files:
        Sigs           : article.rst 

Log message:
        finpoint

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

Patches:
Index: manuscripts/Sigs/article.rst
diff -u manuscripts/Sigs/article.rst:1.125 manuscripts/Sigs/article.rst:1.126
--- manuscripts/Sigs/article.rst:1.125  Mon May 19 14:59:39 2003
+++ manuscripts/Sigs/article.rst        Mon May 19 15:02:05 2003
@@ -29,29 +29,19 @@
 unlimited time.
 
 We discuss particularly an instance with 
-the full digital signature feature set,
+the full digital signature feature set, 160-bit security,
 which requires
-a 110 KB signature, 175'072 hash invocations to create, and 
-5'568 hash invocations to verify
-
-- probabilistic instance
-
-  - (2^56 private keys)
-
-  - with p XXX safe to sign up to XXX docs
-
-  - 28 KB sig, 175'096 hashes to create, 1'408 hashes to verify
+a 110 KB signature, 175'072 hash invocations for signing, and 
+5'568 hash invocations for verification.
+On a more practical level, we discuss a 
+probabilistically valid instance with 56-bit security
+if only used for up to XXX signatures.
+The probabilistic scheme requires
+a 28 KB sig, 175'096 hash invocations for signing, 1'408 hashes 
+for verification.
 
 - we discuss applications
 
-..  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)
-
 Introduction
 ============
 
@@ -363,6 +353,14 @@
 - 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




reply via email to

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