1.13 A home on the Internet — Ludovic Courtès — Cryptographic Tools
  • Certificate Chain Discovery in SPKI/SDSI [clarke01:spki-sdsi]
    Dwaine Clarke, Jean-Emile Elien, Carl Ellison, Matt Fredette, Alexander Morcos, Ronald L. Rivest, appeared in ACM Journal of Computer Security, January 2001

    A must-read. The idea of private, recursive namespaces is discussed at length and is enlightening. Each participant may bind a key or a name in a foreign namespace into its own private namespace. In practice, each participant may issue name certificates which are signed tuples containing its public key, a local name, the subject that is bound to it (i.e., either a pubic key or a name), and a validity specification. Cross-namespace references result in certificate chains that form a graph. The paper describes a number of useful operations that may be performed on that graph, in particular how to produce a certificate chain demonstrating how a given certificate is within a closure. This turns out to be comparable to the concept of petnames, as depicted by Mark Miller on the erights.org website; however, pet names also allow cryptographic identifiers to be mapped back to local names. On the topic of naming, see also the discussions around SRFI-84.

  • Authentication Mechanisms for ONC RPC (RFC 2695) [chiu99:rfc2695-rpc-auth]
    Alex Chiu (Internet Engineering Task Force (IETF)), September 1999
  • Compare-by-Hash: A Reasoned Analysis [black06:cmpbyhash]
    John Black, Proceedings of the USENIX Annual Technical Conference, Systems and Experience Track, 2006

    A published rebuttal of Henson's paper henson03:cmpbyhash. Another such document is Graydon Hoare's documentation of the Monotone versioning system monotone05:website.

  • Using OpenPGP Keys for TLS Authentication (IETF Internet Draft) [mav06:draft-tls-openpgp]
    Nikos Mavrogiannopoulos (Internet Engineering Task Force (IETF)), July 2006

    Nice draft, written by one of the original author of GnuTLS.

  • An Analysis of Compare-by-hash [henson03:cmpbyhash]
    Val Henson (Sun Microsystems), Proceedings of HotOS IX: The 9th Workshop on Hot Topics in Operating Systems, May 2003

    An attack against content-based addressing (here referred to as compare-by-hash) and its use in systems such as Monotone monotone05:website. I was quite reluctant to read this at first since the paper ends by a advertisement of proprietary SCM BitKeeper. However, it does present interesting arguments which may be summarized as follows:

    1. actual input is not random; consequently, using the probability of collisions for random input is not relevant;
    2. cryptographic hash functions may be obsoleted overnight as one demonstrates how to produce collisions more quickly than with brute force;
    3. collisions result in silent errors which are not transitory, unlike hardware errors
    4. comparing the probability of a hash collision with that of a hardware error is not relevant since, even with a low collision probability, certain hash functions can be made unusable (think of MD5);
    5. finally, the author believes that software should improve the reliability of computer systems, not the opposite.
    This is actually quite convincing. The author, however, notes that compare-by-hash may still be appropriate in software whose errors affect only its single user (such as Rsync), provided the user is informed about the potential of silent errors. Therefore, the author considers the use of compare-by-hash inappropriate in situation where the namespace is shared among several users as in LBFS, Venti, Pastiche, and similarly many other versioning, file sharing, etc. systems. Quite convincing, and sad.

    The author goes on to note than an alternative to this approach, in most cases, is to have software keep state, for instance about which blocks it has already sent, etc. This is much less convenient, indeed, but safer.

    Now, let's read the counter-attack monotone05:website. As stated there, Henson seems to be unaware of the theoretical background of cryptographic hashes. In particular, he does not even mention preimage-resistance. A published counter-attack is black06:cmpbyhash.

  • Establishing Identity Without Certification Authorities [ellison96:establishing]
    Carl M. Ellison (CyberCash, Inc.), Proceedings of the Sixth USENIX Security Symposium, 1996

    This paper provides a nice clarification of the identity/authentication topic. Quoting the author, the thesis here is that an identity certificate issued by a CA is "neither necessary nor sufficient" to be sure a public key belongs to a particular person. It starts by defining the term ``identity'': "the distinguishing character or personality of an individual". It discusses existing ``certificates'' (X.509, PGP, and driver licences), as well as naming issues (pretty much as in miller06:robust and Zooko's Triangle). It then explains that ways to make sure a public key belongs to a particular entity heavily depend on the kind of relationship on has with that entity: personal contact, network acquaintance, stranger, old friend out of touch. Basically, the ``network acquaintance'' case is the easiest, assuming messages exchanged by both parties have always been digitally signed: in this case, one's perception of the other (their "distinguishing character") is tightly bound to "digital communications strongly tied to a public key". The stranger case is also very easy: getting back to the definition of ``identity'', if someone is a total stranger, then there is "nothing to risk by binding his key to a still meaningless nickname". Finally, the author shows that the ``old friend, out of touch'' case is harder. They propose a protocol to bind identity to keys in this situation that (i) uses common knowledge (e.g., ``who was your girlfriend back in 1979?'') and (ii) allows both parties to estimate the chance of being subject to a man-in-the-middle attack. Basically, both parties prepare questions as well as a list of possible (expected) answers, and exchange their answers in the form of the hash of both the answer and their public key, such that a man in the middle can hardly forge a correct answer.

  • The Transport Layer Security (TLS) Protocol, Version 1.1 (RFC 4346) [dierks06:rfc4346-tls]
    Tim Dierks, Eric Rescorla, Win Teerse (Internet Engineering Task Force (IETF)), April 2006

    The well-known TLS protocol, version 1.1. This supersedes version 1.0, defined in RFC 2246 (Jan. 1999).

  • Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) (RFC 4492) [blake-wilson06:rfc4492-tls-ecc]
    Simon Blake-Wilson, Nelson Bolyard, Vipul Gupta, Chris Hawk, Bodo M?ller (Internet Engineering Task Force (IETF)), May 2006
  • XDR: External Data Representation Standard (RFC 4506) [eisler06:rfc4506-xdr]
    Mike Eisler (Internet Engineering Task Force (IETF)), May 2006

    The XDR binary serialization format used by ONC RPC srinivasan95:rfc1831-onc-rpc.

  • RPC: Remote Procedure Call Protocol Specification, Version 2 (RFC 1831) [srinivasan95:rfc1831-onc-rpc]
    Raj Srinivasan (Internet Engineering Task Force (IETF)), August 1995

    The Sun/ONC RPC protocol specifications, version 2. This seems to supersede RFC 1057 which did not yet use the term ``ONC RPC''.

  • Finding Collisions in the Full SHA-1 [wang05:collisions]
    Xiaoyun Wang, Yiqun Yin, Hongbo Yu, Proceedings of the CRYPTO Conference, 2005

    The name says it all. The attacks can find collisions in the full version of SHA-1, requiring fewer than 269 operations (a brute force search would require 280 operations). See also the excellent article on Wikipedia.

  • Using OpenPGP Keys for Transport Layer Security Authentication (RFC 5081) [mav07:rfc5081-tls-openpgp]
    Nikos Mavrogiannopoulos (Internet Engineering Task Force (IETF)), November 2007

    Nice RFC, written by one of the original author of GnuTLS.

  • Portfolio of Recommended Cryptographic Primitives [nessie03:portfolio]
    NESSIE Consortium, February 2003

    This is an actual recommendation. For collision-resistant hash functions, the conclusion is:

    The collision-resistant hash functions included in the NESSIE portfolio are Whirlpool, SHA-256, SHA-384 and SHA-512. [...]
    The standard primitives SHA-1 and RIPEMD-160 do not meet the NESSIE security requirement for symmetric primitives, because their output is only 160 bits, but they can be recommended for applications where this security level is sufficient.

  • The GNU TLS Library [josefsson06:gnutls]
    Simon Josefsson, Nikos Mavrogiannopoulos, 2006

    The only TLS implementation that supports the OpenPGP certificate extension mav06:draft-tls-openpgp.

  • Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control [miller06:robust]
    Mark Samuel Miller (Johns Hopkins University, Baltimore, MA, USA), May 2006

    This thesis is a must-read. Among other things, it studies capability-based systems and bases the design of a programming language, E, on some of the principles commonly referred to in the design of ``secure'' operating systems like EROS and its close relatives. Section 3.5 contains an interesting discussion on related work in the area of designation in distributed systems and mentions SDSI/SPKI clarke01:spki-sdsi as well as ellison96:establishing.

  • SPKI Certificate Theory (RFC 2693) [ietf99:rfc2693]
    Carl M. Ellison, Bill Frantz, Butler Lampson, Ron Rivest, Brian Thomas, Tatu Ylonen (Internet Engineering Task Force (IETF)), September 1999

    A description of SPKI(/SDSI) from a theoretical viewpoint. Naming in particular is discussed, as shown in clarke01:spki-sdsi.

  • RPCSEC_GSS Protocol Specification (RFC 2203) [eisler97:rfc2203-rpcsec-gss]
    Michael Eisler, Alex Chiu, Lin Ling (Internet Engineering Task Force (IETF)), September 1997
  • Security Performance [menasce03:security]
    Daniel A. Menasc? (George Mason University, Fairfax, VA, USA), appeared in IEEE Internet Computing, June 2003

    A short discussion of encryption and digital signature, showing the relative performance of various techniques. In particular, the author notes that:

    • "Symmetric key encryption is orders of magnitude faster than public key encryption."
    • "Private key operations are generally slower than those with public keys."

  • OpenPGP Message Format (RFC 2440) [callas98:rfc2440-openpgp]
    Jon Callas, Lutz Donnerhacke, Hal Finney, Rodney Thayer (Internet Engineering Task Force (IETF)), November 1998
  • NESSIE Security Report [nessie03:security]
    NESSIE Consortium, February 2003

    Discusses ciphering and cryptographic hash functions for use as a standard "for the European market". It evaluates functions but does not issue recommendations. The conclusion is that Whirlpool and SHA-2 are safer than SHA-1 but states that the attack found on SHA-1 is "not a threat for any normal use of the hash function".

  • Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure [ellison00:ten-risks]
    Carl Ellison, Bruce Schneier, appeared in Computer Security Journal, 2000

    See also this response/rebuttal.

  • RPC: Remote Procedure Call Protocol Specification, Version 2 (RFC 1057) [srinivasan88:rfc1057-sun-rpc]
    Raj Srinivasan (Internet Engineering Task Force (IETF)), June 1988

    The Sun RPC protocol specifications, version 2 (supersedes RFC 1050).

  • Authentication for Pervasive Computing [creese04:auth]
    Sadie Creese, Michael Goldsmith, Bill Roscoe, Irfan Zakiuddin, Lecture Notes in Computer Science, 2004

    This paper addresses authentication in pervasive computing and its examples are borrowed from that specific area. For instance, the author considers the authentication of a binding between a public key and a specific physical printer in an airport. Likewise, its second example is the authentication of bindings between public keys and the PDAs of colleagues present in the same meeting room. That sort of authentication, which involves both the physical and electronic world, requires specific arrangements, such as having the users (the persons) share a secret through some secure channel (e.g., telling a password to all the people present in the meeting room) in order to bootstrap the authentication process. The author also mixes unrelated issues such as getting confidence in the printer's behavior and advocates some form of remote attestation to that end.

(made with skribilo)