Rolf Oppliger’s CRYPTOLOGY Blog

As of this writing, there are a few early adopters who have already implemented and rolled out Kyber-enhanced hybrid PQC, such as Signal with its post-quantum extended Diffie-Hellman (PQXDH) , Apple with PQ3 for iMessage, Google with respective cipher suites for Chrome, and Cloudflare to support these cipher suites on the server side. There are less implementations and deployments of PQ-resistant digital signatures though. This is because the respective signature schemes have some disadvantages that make it a truly challenging task to use and deploy them in the field (this is why the NIST has called for additional proposals for its PQC standardization process). Generally speaking, the trend to enhance cryptographic protocols, services, and products with PQC is going on, and it will certainly become a must criterion to support PQC anytime soon (simply to be sure to mitigate so-called “harvest now, decrypt later” attacks). Some companies have already published PQC-related threat models and respective strategies, such as Google, and many other companies will follow. Anyway, implementing a hybrid approach and cryptographic agility are keys to a successful deployment of PQC.

When SSL/TLS is in use, Wireshark only sees encrypted data by default. This is a problem, if one wants to use Wireshark to inspect and view an SSL/TLS handshake protocol transcript. To make SSL/TLS traffic accessible to Wireshark, it is necessary to make the keying material used by the SSL/TLS session available to Wireshark. This can be done by configuring the operating system-level environment variable SSLKEYLOGFILE point to a file (that causes some browsers to deposit the SSL/TLS keys they use in this file), and configuring Wireshark to make use of this file. A respective description from Comapitech is available here.

Galois/Counter Mode (GCM) is a standardized mode of operation for a block cipher that provides authenticated encryption with associated data (AEAD). As such, it has many applications in the field – especially when combined with the Advanced Encryption Standard (AES). You may download an 8-page description of AES-GCM here.

Keccak is a cryptographic hash function that was submitted to the respective NIST competition in 2007. It won the competition and finally became the SHA-3 standard in 2012. As such, it nicely complements SHA-2 and is specified in FIPS PUB 202. You may download a 15-page description of Keccak and SHA-3 here.

In a recent ePrint report, Ange Albertini et al. point out a subtle problem that is also relevant for authenticated encryption and AE(AD) ciphers: There are file formats that are not mutually exclusive in the sense that the content of a given file may be valid according to different file formats. In the case of two formats, for example, a respective file refers to a binary polyglot – it is valid for (at least) two different file formats. Two different ciphertexts may be packed into a binary polyglot. Depending on the decryption key, two different but valid plaintext messages can be recovered from the encrypted file. This works independently from the AE(AD) cipher that may otherwise be secure. It goes without saying that this may pose a serious problem and security risk in some situations. There are basically two possibilities to mitigate the risk: Either the file formats can be sharpened in a way that polyglots cannot exist, or – maybe more realistically – the AE(AD) cipher may be extended to additionally provide support for key commitment, meaning that the encryption process must also commit to the key that is being used. This should make it impossible to decrypt a given ciphertext with another key than originally anticipated. There are multiple ways to achieve this, for example, by adding an additional zero block prior to encryption and verifying that this block is recovered after decryption. This is conceptually similar to the quick check used in some OpenPGP implementations. Anyway, it is reasonable to expect that key commitment will become relevant in authenticated encryption in the future.

Both attacks refer to a man-in-the-middle (MITM) attacks, in which an adversary – acting as a MITM – tries to inject data before the client is properly authenticated. This data is then passed to the application together with the data provided by the client after authentication. Because the application cannot properly distinguish the data injected before authentication and the data provided afterwards, several attacks become feasible. The IETF originally crafted a renegotiation_info extension to mitigiate such attacks. In 2014, however, it was shown that this extension is not sufficient, and that a special form of renegotiation attack – a so-called triple handshake attack or 3SHAKE attack, in short – is still feasible, and hence the IETF had to craft another extension (called extended_master_secret ) to mitigate the attack. You may download a 7 page description of the attacks and the respective mitigation technologies here.

Salsa20 is a new variable-round stream cipher developed by Dan Bernstein in 2005. It is used in many Internet applications as a replacement for RC4 that has been shown to have statistical defects. ChaCha20 is a modified version of Salsa20 specified in RFC 7539 together with the Poly-1305 message authentication mechanism. As such, it is one of the five standardized AEAD ciphers that can be used in TLS 1.3. You may download a 9-page description of Salsa20 and ChaCha20 here.

Please, leave your question as a comment to this post or e-mail it to cryptolog@esecurity.ch. In either case, your question is highly appreciated.