wiki:Bibliography

Version 71 (modified by zooko, at 2012-11-24T18:25:26Z) (diff)

add Haver and Ruud's paper

See also OneHundredYearCryptography.

Here are some papers that are potentially of interest.

Crypto

Symmetric Primitives

Ciphers

Hash Functions

Combiners a.k.a. Multiple Encryption a.k.a. Cascade Ciphers
Hash Function Combiners
Cipher Combiners

Public Key Cryptography

Hash-Based Digital Signatures

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.”

Elliptic Curve Cryptography

  • ​Ed25519 fast, well-engineered elliptic curve digital signatures by Daniel J. Bernstein
  • ​On the Security of 1024-bit RSA and 160-bit Elliptic Curve Cryptography crypto gurus try to predict whether 160-bit elliptic curve crypto can be brute-force-cracked in the next decade. They conclude: "Right now most certainly not: 2.5 billion PS3s or equivalent devices (such as desktops) for a year is way out of reach. In a decade, very optimistically incorporating 10-fold cryptanalytic advances, still millions of devices would be required, and a successful open community attack on 160-bit ECC even by the year 2020 must be considered very unlikely."
  • ​The Certicom Challenges ECC2-X other crypto gurus launch an effort to brute-force-crack 130-bit and 160-bit ECC.

Erasure Coding

Direct Attached Storage

Local Filesystems

(Summary: basically it looks to me (Zooko) like reiser3 is better-engineered for handling faults than are the other local filesystems. See also the recent revelation that ext3 has been running with write barriers turned off all this time: ​http://lwn.net/Articles/283161 .)

Disk Failure Rates

P2P / Distributed Systems / Decentralization

See Also

The Back Shelf

These are some references which are less interesting or relevant than the ones above.

Public Key Cryptography

  • ​Efficient Signature Schemes with Tight Reductions to the Diffie-Hellman Problems Scheme 1 in this paper comes with a tight reduction to the Computational Diffie-Hellman problem, which means it is definitely at least as secure as any discrete-log-based scheme and could be more secure. It also has a good pedigree (having been suggested by David Chaum et al. in 1989 and having been proven to tightly reduce to Computational Diffie-Hellman by Katz et al. in 2003). It also has a nice short public key, which could be good for fitting it into our capability security schemes.
  • ​ECC Brainpool Standard Curves and Curve Generation new elliptic curve parameters which come with a proof that they were generated deterministically and pseudorandomly from the first few bits of Π, as well as proofs that they are immune to certain other potential cryptographic weaknesses.

Miscellaneous

  • ​POST: A Secure, Resilient, Cooperative Messaging System -- use a DHT for messaging; includes a suggestion to ameliorate the confidentiality problems of single-instance store by adding random bits to small text messages
  • ​Non-Transitive Connectivity and DHTs -- practical lessons in dealing with not-fully-connected DHTs that theoreticians learned in deployment
  • ​Measurement and Analysis of TCP Throughput Collapse in Cluster-based Storage Systems -- Hm... Could this happen to us?
  • ​Endomorphisms for faster elliptic curve cryptography on general curves techniques to compute elliptic curve cryptography significantly faster in software.
  • ​Some thoughts on Collision Attacks in the Hash Functions MD5, SHA-0 and SHA-1 general musings about design of secure hash functions
  • ​EnRUPT a very simple, fast, and flexible primitive which could be used as stream cipher, secure hash function, or MAC (the first two are primitives that we currently need, and the third one -- MAC -- is a primitive that we may want in the future) and which relies for its security on a large number of rounds. The question of how many rounds to use is decided by semi-automated cryptanalysis. (Note: the SHA-3 candidate version of EnRUPT in stream hashing mode was insecure. The current block cipher mode is insecure. There is a minor change (use a few more rounds) which is thought to fix the stream hashing mode. The author is apparently working on a fix for the block cipher mode.)
  • ​defectoscopy.com 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 defines and analyzes the HKDF Key-Derivation Algorithm; A KDF is a linchpin component of our crypto schemes.
  • ​ChaChaCha20 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 by Mendel and Rijmen
  • ​Digital Signatures out of Second-Preimage Resistant Hash Functions 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 by Buchmann, Dahmen, and Szydlo; A survey of why it might be a good idea.
  • ​Merkle Signatures with Virtually Unlimited Signature Capacity 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 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 [Merkle Signatures with Virtually Unlimited Signature Capacity], 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.
  • ​Bitsliced AES implementation The faster and timing resistant implementation of AES-CTR in bitsliced mode by Peter Schwabe and Emilia Kasper.
  • ​Vector permutations and AES The fast and timing-resistant implementations of Mike Hamburg using vector permute instructions (read: pshufb and vperm).