tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

move hash-based digsig papers to the right section 

[Imported from Trac: page Bibliography, version 79]
daira 2015-03-25 09:09:51 +00:00
parent 689b8a062a
commit 39f9c2c437
1 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
Bibliography.md

@ -44,6 +44,10 @@ Here are some papers that are potentially of interest.
#### Hash-Based Digital Signatures
* [XMSS - A Practical Forward Secure Signature Scheme based on Minimal Security Assumptions](http://eprint.iacr.org/2011/484) by Buchmann, Dahmen, Hülsing; “the first provably forward secure and practical signature scheme with minimal security requirements: a pseudorandom and a second preimage resistant (hash) function family. Its signature size is reduced to less than 25% compared to the best provably secure hash based signature scheme.”
* [Digital Signatures out of Second-Preimage Resistant Hash Functions](http://www.cdc.informatik.tu-darmstadt.de/~dahmen/papers/DOTV08.pdf) by Dahmen, Okeya, Takagi, Vuillame; This scheme is secure as long as the underlying hash function has *second-preimage resistance*, which real hash functions are a lot more likely to have than to have a stronger property like *collision-resistance*.
* [Hash-based Digital Signature Schemes](http://www.cdc.informatik.tu-darmstadt.de/~dahmen/papers/hashbasedcrypto.pdf) by Buchmann, Dahmen, and Szydlo; A survey of why it might be a good idea.
* [Merkle Signatures with Virtually Unlimited Signature Capacity](http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=8AC81C407AA3CBF35093032BD01F3085?doi=10.1.1.95.1374&rep=rep1&type=pdf) by Buchmann, Dahmen, Klintsevich, Okeya, and Vuillaume; includes treating the parameters as an optimization problem and solving it with various weights or constraints to find various good settings for the parameters. Unfortunately their weights and constraints are different from hours: they thought it was fine to let key generation time take tens of hours! We want key generation time to be as few milliseconds as possible. A good rule of thumb for us would probably be try to reduce the time of whichever of the three operations is the slowest: key-generation, signing, and verification.
* [Fast Hash-Based Signatures on Constrained Devices](https://www.minicrypt.cdc.informatik.tu-darmstadt.de/reports/reports/REDBP08.pdf) by Rohde, Eisenbarth, Dahmen, Buchmann, and Paar; a case study of implementing hash-based digital signatures for a 8-bit microcontroller. Their implementation had some trade-offs that we wouldn't want: it is a "key-evolving" design (the signer has to maintain state in order to avoid a security failure), it can only handle a limited number of signatures, and they spent a lot of time in key generation. Hm, they don't say how long key-generation took in this paper—only that it took so long that they had to run it on a PC instead of on their microcontroller. In [Signatures with Virtually Unlimited Signature Capacity]Merkle, the key-generation took tens of hours on a PC!!! On the other hand, they do show a digital signature scheme which is faster at signing and verifying and is also arguably safer than RSA or ECDSA on their 8-bit microcontroller.
#### Elliptic Curve Cryptography
@ -104,10 +108,6 @@ These are some references which are less interesting or relevant than the ones a
* [defectoscopy.com](http://defectoscopy.com/results.html) a table of semi-automated cryptanalysis results from the inventors of EnRUPT. This technique has not been peer-reviewed by other cryptographers. I (Zooko) can't judge how valid it is. Note that MD4, MD5, SHA-0, SHA-1, SHA-2-256, and GOST are predicted to be insecure, while Tiger is predicted to be secure. AES-128 is predicted to be insecure. Salsa20 is predicted to be secure.
* [HKDF full paper](http://webee.technion.ac.il/~hugo/kdf/kdf.pdf) defines and analyzes the *HKDF* Key-Derivation Algorithm; A KDF is a linchpin component of our crypto schemes.
* [ChaChaCha20](http://cr.yp.to/chacha.html) even better stream cipher; It might be slightly safer than Salsa20 and it is certainly slightly faster on some platforms, but slightly slower on others. However, the author of Salsa20 and ChaChaCha20, Daniel J. Bernstein, seems to have settled on using Salsa20 (or a tweak of it named XSalsa20), so probably that is the one to use.
* [Cryptanalysis of the Tiger Hash Function](https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=81263) by Mendel and Rijmen
* [Digital Signatures out of Second-Preimage Resistant Hash Functions](http://www.cdc.informatik.tu-darmstadt.de/~dahmen/papers/DOTV08.pdf) by Dahmen, Okeya, Takagi, Vuillame; This scheme is secure as long as the underlying hash function has *second-preimage resistance*, which real hash functions are a lot more likely to have than to have a stronger property like *collision-resistance*.
* [Hash-based Digital Signature Schemes](http://www.cdc.informatik.tu-darmstadt.de/~dahmen/papers/hashbasedcrypto.pdf) by Buchmann, Dahmen, and Szydlo; A survey of why it might be a good idea.
* [Merkle Signatures with Virtually Unlimited Signature Capacity](http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=8AC81C407AA3CBF35093032BD01F3085?doi=10.1.1.95.1374&rep=rep1&type=pdf) by Buchmann, Dahmen, Klintsevich, Okeya, and Vuillaume; includes treating the parameters as an optimization problem and solving it with various weights or constraints to find various good settings for the parameters. Unfortunately their weights and constraints are different from hours: they thought it was fine to let key generation time take tens of hours! We want key generation time to be as few milliseconds as possible. A good rule of thumb for us would probably be try to reduce the time of whichever of the three operations is the slowest: key-generation, signing, and verification.
* [Fast Hash-Based Signatures on Constrained Devices](https://www.minicrypt.cdc.informatik.tu-darmstadt.de/reports/reports/REDBP08.pdf) by Rohde, Eisenbarth, Dahmen, Buchmann, and Paar; a case study of implementing hash-based digital signatures for a 8-bit microcontroller. Their implementation had some trade-offs that we wouldn't want: it is a "key-evolving" design (the signer has to maintain state in order to avoid a security failure), it can only handle a limited number of signatures, and they spent a lot of time in key generation. Hm, they don't say how long key-generation took in this paper—only that it took so long that they had to run it on a PC instead of on their microcontroller. In [Signatures with Virtually Unlimited Signature Capacity]Merkle, the key-generation took tens of hours on a PC!!! On the other hand, they do show a digital signature scheme which is faster at signing and verifying and is also arguably safer than RSA or ECDSA on their 8-bit microcontroller.
* [Cryptanalysis of the Tiger Hash Function](https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=81263) by Mendel and Rijmen
* [Bitsliced AES implementation](http://www.cryptojedi.org/crypto/index.shtml#aesbs) The faster and timing resistant implementation of AES-CTR in bitsliced mode by Peter Schwabe and Emilia Kasper.
* [Vector permutations and AES](http://crypto.stanford.edu/vpaes/) The fast and timing-resistant implementations of Mike Hamburg using vector permute instructions (read: pshufb and vperm).