Some of the things I've done and I like

  • NIST Post-Quantum Cryptography Submissions

  • NewHope, Algorithm Specications and Supporting Documentation - Round 1, Erdem Alkim, Roberto Avanzi, Joppe Bos, Leo Ducas, Antonio de la Piedra, Thomas Poppelmann, Peter Schwabe, Douglas Stebila Version 1.0 - November 30, 2017.

    NIST Post-Quantum Cryptography NewHope, Algorithm Specications and Supporting Documentation - Round 2, Erdem Alkim, Roberto Avanzi, Joppe Bos, Leo Ducas, Antonio de la Piedra, Thomas Poppelmann, Peter Schwabe, Douglas Stebila, Martin R. Al- brecht, Emmanuela Orsini, Valery Osheter,Kenneth G. Paterson, Guy Peer, Nigel P. Smart March 15, 2019.
  • Academia and industry publications

  • Antonio de la Piedra, Ghidra-EVM: Reversing Smart Contracts with Ghidra, Black Hat Asia 2021, Singapore, May 4-7, 2021.

    Wouter de Groot, Kostas Papagiannopoulos, Antonio de la Piedra, Erik Schneider, Lejla Batina, Bitsliced Masking and ARM: Friends or Foes? LIGHTSEC 2016, Aksaray University, Cappadocia, Turkey, September 21-22 2016.

    Antonio de la Piedra, Efficient implementation of AND, OR and NOT operators for ABCs. In Liqun Chen, Yongfei Han, editors, The 7th International Conference on Trusted Systems – INTRUST 2015, Beijing, China, December 7-8 2015.

    Lejla Batina, Domagoj Jakobovic, Nele Mentens, Stjepan Picek, Antonio de la Piedra, Dominik Sisejkovic, S-box pipelining using genetic algorithms for high-throughput AES implementations: How fast can we go?, INDOCRYPT 2014, New Delhi, India, December 14-17 2014.

    Antonio de la Piedra, Jaap-Henk Hoepman, and Pim Vullers, Towards a Full-Featured Implementation of Attribute Based Credentials on Smart Card. In A. Kiayias and D. Gritzali, editors, 13th Int. Conf. on Cryptology and Network Security – CANS 2014, Heraklion, Crete, Greece, October 22-24 2014.

    Antonio de la Piedra, An Braeken, Abdellah Touhafi, Leveraging the DSP48E1 Block in Lightweight Cryptographic Implementations, Healthcom 2013.

    Antonio de la Piedra, An Braeken, Abdellah Touhafi, Compact implementation of the GCM and CCM modes of AES Using DSP Blocks, FPL 2013.

    An Braeken, Antonio de la Piedra, Karel Wouters, Secure Event Logging in Sensor Networks. In: EuroPKI 2011, Public Key Infrastructures, Services and Applications, Lecture Notes in Computer Science, 7163, Springer Berlin Heidelberg, pp.194-208, 978-3-642-29803-5, 2012.

    Antonio de la Piedra, An Braeken, Abdellah Touhafi, Karel Wouters, Secure event logging in sensor networks, Computers and Mathematics with Applications. ISSN 0898-1221. 2012.

  • Technical Reports

  • Beyond the selective disclosure of ABCs on RAM-constrained devices, Antonio de la Piedra 2016. Available at Cryptology ePrint Archive: Report 2016/031

    Integration of hardware tokens in the Idemix library, Antonio de de la Piedra. Available at http://eprint.iacr.org/2014/691, Cryptology ePrint Archive: Report 2014/691 .

Software


    • EVM module for Ghidra (2020, Java/Python/SLEIGH): ghidra-evm consists of a Software processor module, a loader and different plugins to reverse engineering smart contracts written for the Ethereum Virtual Machine (EVM).

    • New Hope KEM optimization for MIPS64 (2017, ASM) Optimized assembly version for MIPS64 of the New Nope KEM that was submitted to the NIST PQC project.

    • SHA-3 Keccak f-1600 permutation for MIPS64 (2017, ASM). Optimized assembly version for MIPS64 of the f-1600 permutation of SHA-3. Part of the New Hope implementation that was submitted to the NIST PQC project.

    • Implementation of the PRESENT lightweight block cipher, bitsliced and 2nd order protected for ARM (2016, ASM). Part of the LIGHTSEC 2016 publication: Wouter de Groot, Kostas Papagiannopoulos, Antonio de la Piedra, Erik Schneider, Lejla Batina, Bitsliced Masking and ARM: Friends or Foes? LIGHTSEC 2016, Aksaray University, Cappadocia, Turkey, September 21-22 2016.

    • Protocol extensions for the IRMA card (2014-2015, C, ASM, Python). Taylored implementation of pseudonyms and AND, NOT and OR operators (non-interactive zero-knowledge proofs) of the private credential system of IBM Idemix for the MULTOS smart card platform with terminal client in Python.

    • IRMA (2014, C, ASM) I Reveal My Attributes (IRMA) is an open-source implemen- tation on Smart Cards of the IBM Identity Mixer based on the MULTOS platform.

    • The Simple Library for Verifying and Issuing Attributes (Silvia) (2014) Additional support for managing a Smart Card implementation of anonymous credentials based on the IBM Identity Mixer (IRMA).

    • Open eCard (2013) Implementation of the Service Access Layer (SAL) together with serveral add-ons for integrating an anonymous-based credential system (Idemix).

    • CHARM (2013-2014, Python) The CHARM library provides implementations of complex cryptographic primitives for building protocols such as blind signatures, commitments, zero-knowledge proofs and credential systems. I implemented several partial blind and blind signatures for this library: M. Abe, A Secure Three-move Blind Signature Scheme for Polynomially Many Signatures, M. Abe, T. Okamoto, Provably Secure Partially Blind Signatures, and J. Camenisch, A. Lysyanskaya, A Signature Scheme with Efficient Protocols.

    • OpenCores (2009-2013, VHDL) Hardware implementation of several light-weight block ciphers, hashing algorithms, ECC operations and the physical layer of the IEEE 802.15.4 communication protocol: SHA-256 Core, IEEE 802.15.4 Core (physical layer), B-163 EC Arithmetic, DQPSK Mapper, XTEA Core, DES Core, DESL Core, DESX Core, DESLX Core, IEEE 802.15.4 CRC, AES cores (compact), NOEKEON Core (lightweight block cipher).

    • snort2c (2005, C, OpenBSD/POSIX) Integration of the Snort Intrusion Detection System (IDS) with the OpenBSD packet filter PF. FreeBSD Snort2pfcd is based on my code (Github link).

Bugs, CVEs and Security Advisories


    • Gnu TLS 3.6.14: Unintended use of sizeof() on pointer type. Misuse of sizeof() with pointers in the padlock extension of VIA processor when performing SHA-1.

    • Mbed TLS 2.23.0: Unintended use of sizeof() on pointer type. Misuse of sizeof() with in pointers in the AES ECB implementation. During AES encryption and decryption cryptographic implementations operations (mbedtls_internal_aes _encrypt() and mbedtls_internal _aes_decrypt()), the variable containing the round keys is incorrectly zeroized: a sizeof() of a pointer is taken instead.

    • CVE-2020-17478: Crypt::Perl::ECDSA module before 0.33 relies on the double-and- add algorithm to implement the EC scalar multiplication operation. The double- and-add algorithm leaks the secret nonce length. Hence, when used in combination with ECDSA it is possible to recover the private key involved in the creation of a signature via the BKZ lattice reduction algorithm.

    • wolfssl-4.4.0: ed448 and edDSA via curve 25519 signatures implementations do not validate correctly the length of the inputs thus creating malleability problems in wolfssl. If they are use for authorization purpose an attacker can extend the length of the signature in order to create another valid signature.

    • CVE-2020-14968: An issue was discovered in the jsrsasign package before 8.0.17 for Node.js. Its RSASSA-PSS (RSA-PSS) implementation does not detect signature manipulation/modification by prepending ’0’ bytes to a signature (it accepts these modified signatures as valid). An attacker can abuse this behavior in an application by creating multiple valid signatures where only one signature should exist. Also, an attacker might prepend these bytes with the goal of triggering memory corruption issues. See also npm.js Advisory no. 1541.

    • CVE-2020-14967: An issue was discovered in the jsrsasign package before 8.0.18 for Node.js. Its RSA PKCS1 v1.5 decryption implementation does not detect ciphertext modification by prepending ’0’ bytes to ciphertexts (it decrypts modified ciphertexts without error). An attacker might prepend these bytes with the goal of triggering memory corruption issues.

    • CVE-2020-14966: An issue was discovered in the jsrsasign package through 8.0.18 for Node.js. It allows a malleability in ECDSA signatures by not checking overflows in the length of a sequence and ’0’ characters appended or prepended to an integer. The modified signatures are verified as valid. This could have a security-relevant impact if an application relied on a single canonical signature.

    • wolfssl-4.4.0: When using the ECDSA signing implementation of wolfssl-4.4.0 with the curve secp256r1 it is possible to sign a message using (0, 0) as public key and 0 as private key (that is, pre-generated points on the degenerate line y:x = 0). The wc_ecc_import_raw function does not validate if the points belong to the curve which makes it possible to generate (r, s) pairs that leak the nonce used during signature generation.

    • CVE-2020-13895: Crypt::Perl::ECDSA module before 0.32 Crypt::Perl::ECDSA fails to verify correct ECDSA signatures when r and s are small and when s = 1. This happens when using the curve secp256r1 (prime256v1). This could conceivably have a security-relevant impact if an attacker wishes to use public r and s values when guessing whether signature verification will fail.

    • CVE-2020-13822: Elliptic package 6.5.2 for Node.js (2020, JS) The Elliptic package 6.5.2 for Node.js allows ECDSA signature malleability via variations in encoding, leading "0" bytes, or integer overflows. This could conceivably have a security- relevant impact if an application relied on a single canonical signature.

    • CVE-2020-13757: python rsa 4.0 (2020, python) Python-RSA 4.0 ignores leading "0" bytes during decryption of ciphertext. This could conceivably have a security- relevant impact, e.g., by helping an attacker to infer that an application uses Python- RSA, or if the length of accepted ciphertext affects application behavior (such as by causing excessive memory allocation).

    • CVE-2020-12607: python fast-ecdsa-2.1.1 (2020, python) In certain cases, for an ap- plication using fast-ecdsa 2.1.1, an attacker can benefit from the fact that signatures are not checked correctly. For instance, if they are used to enforce access control, specific public keys used to verify signatures and then authorize different function- alities of an application will fail for certain users. Based on the extreme parameters of k and s − 1 and having access to the public key used to signature verification an attacker can guess for which user the signature verification will fail.