*21:17* [Pub][ePrint]
HIMMO security, by Oscar Garcia-Morchon and Ronald Rietman and Ludo Tolhuizen and Domingo Gomez-Perez and Jaime Gutierrez
This paper describes HIMMO, an identity-based pairwise symmetric key establishment method. The acronym \"HIMMO\" is derived from two interpolation problems that are essential for thesecurity of the scheme: the HI problem, which is related to the

well-known noisy interpolation problem, and the apparently novel MMO problem, presented at ISSAC\'14.

HIMMO is non-interactive: nodes in a network can directly generate a common key without exchanging messages. Each node in the network has an identifier, and a trusted third pay (TTP) provides it with secret keying material---linked to the node identifier---in a secure way.

A node that wishes to communicate with another node uses its own secret keying material and the identity of the other node to generate a common pairwise key.

HIMMO allows for efficient operation with respect to both the amount of stored keying material and the key computation time, which is especially relevant for resource-constrained devices.

It has similar operational characteristics as previous ID-based symmetric key establishment methods, but has superior resistance against attacks in which multiple colluding or compromised nodes co-operate to obtain information on keys between other non-colluding or non-compromised nodes.

*21:17* [Pub][ePrint]
Bounded Pre-Image Awareness and the Security of Hash-Tree Keyless Signatures, by Ahto Buldas and Risto Laanoja and Peeter Laud and Ahto Truu
We present a new tighter security proof for unbounded hash tree keyless signature (time-stamping) schemes that use Merkle-Damg\\aa rd (MD) hash functions with Preimage Aware (PrA) compression functions. It is known that the PrA assumption alone is insufficient for proving the security of unbounded hash tree schemes against back-dating attacks. We show that many known PrA constructions satisfy a stronger \\emph{Bounded Pre-Image Awareness (BPrA)} condition that assumes the existence of an extractor $\\EXT$ that is bounded in the sense that for any efficiently computable query string $\\alpha$, the number of outputs $y$ for which $\\EXT(y,\\alpha)$ succeeds does not exceed the number of queries in $\\alpha$. We show that blockcipher based MD-hash functions with rate-1 compression functions (such as Davies-Meyer and Miyaguchi-Preneel) of both type I and type II are BPrA. We also show that the compression function of Shrimpton-Stam that uses non-compressing components is BPrA. The security proof for unbounded hash-tree schemes is very tight under the BPrA assumption. In order to have $2^s$-security against back-dating, the hash function must have $n=2s + 4$ output bits, assuming that the security of the hash function is close to the birthday barrier, i.e. that there are no structural weaknesses in the hash function itself. Note that the previous proofs that assume PrA gave the estimation $n=2s + 2 \\log_2 C + 2$, where $C$ is the maximum allowed size of the hash tree. For example, if $s=100$ ($2^{100}$-security) and $C=2^{50}$, the previous proofs require $n=302$ output bits, while the new proof requires $n=204$ output bits.

*09:17* [Pub][ePrint]
Integration of hardware tokens in the Idemix library, by Antonio de la Piedra
The Idemix library provides the implementation of the Camenisch-Lysyanskaya (CL) Attribute-based Credential System (ABC), its protocol extensions and the U-Prove ABC. In the case of the CL ABC, the library can delegate some cryptographic operations to a hardware token (e.g. a smart card). In the last few years several practitioners have proposed different implementations of ABCs in smartcards. The IRMA card provides at the time of writing this manuscript, an optimal performance for practical applications. In this report, we address the case of integrating this implementation in the Idemix library. We opted for implementing the key binding use case together with the generation of exclusive scope pseudonyms and public key commitments on card. The integration requires two additional classes

(one that parses system parameters, credential specifications and issuer public keys and other one that interfaces the card and its functionalities with the CL building block) together with one modification in the code if the signature randomization is delegated to the card (only required in one of the proposed alternatives). The integration of the key binding use case requires 540 bytes extra in the smart card. We can perform all the involved cryptographic operations in only 206.75 ms, including the computation of exclusive scope pseudonyms (55.19 ms).