See also;

https://bsky.app/profile/campuscodi.risky.biz/post/3lyfghyytj22x

Abstract Common verification steps in cryptographic protocols, such as signature or message authentication code checks or the validation of elliptic curve points, are crucial for the overall security of the protocol. Yet implementation errors omitting these steps easily remain unnoticed, as often the protocol will function perfectly anyways. One of the most prominent examples is Apple's goto fail bug where the erroneous certificate verification skipped over several of the required steps, marking invalid certificates as correctly verified. This vulnerability went undetected for at least 17 months.

We propose here a mechanism which supports the detection of such errors on a cryptographic level. Instead of merely returning the binary acceptance decision, we let the verification return more fine-grained information in form of what we call a confirmation code. The reader may think of the confirmation code as disposable information produced as part of the relevant verification steps. In case of an implementation error like the goto fail bug, the confirmation code would then miss essential elements.

The question arises now how to verify the confirmation code itself. We show how to use confirmation codes to tie security to basic functionality at the overall protocol level, making erroneous implementations be detected through the protocol not functioning properly. More concretely, we discuss the usage of confirmation codes in secure connections, established via a key exchange protocol and secured through the derived keys. If some verification steps in a key exchange protocol execution are faulty, then so will be the confirmation codes, and because we can let the confirmation codes enter key derivation, the connection of the two parties will eventually fail. In consequence, an implementation error like goto fail would now be detectable through a simple connection test.

https://bsky.app/profile/tumbolia.bsky.social/post/3ltyahiem3s2u

We updated our paper on Fiat-Shamir!

We now take a closer look at the gap between what symmetric cryptography has focused on for over 10 years (indifferentiability) and what is actually needed for the soundness of ZKPs and SNARKs (something stronger!).

Opossum is a cross-protocol application layer desynchronization attack that affects TLS-based application protocols that rely on both opportunistic and implicit TLS. Among the affected protocols are HTTP, FTP, POP3, SMTP, LMTP and NNTP.

Note: The vast majority of websites are not vulnerable as HTTP TLS upgrade (RFC 2817) was never widely adopted and no browsers support it.

Via; https://bsky.app/profile/filippo.abyssdomain.expert/post/3lrdvmvj6kj2p