🗓️ 15 December 2023 @ 11:30 CET
📍 Via Giovanni Battista Martini, 3 - Room A
#CIFRIS23 is an international event, supported and organized by De Cifris, aimed at bringing together researchers in the field of #cryptography, practitioners, developers, and users to foster cooperation and exchange techniques, tools, experiences, and ideas.
When Thomas Oliver and Kyu-Hwan Lee used machine learning techniques to predict the ranks of elliptic curves with high accuracy, they noticed hidden oscillations reminiscent of bird murmurations. That pattern was not noticed by mathematicians before, and an explicit formula for those was found by Nina Zubrilina.
Looking for conferences on #Cryptography and #Security. #AfricaCrypt is in #Cameroon this year, a country that imprisons peolpe for suspicions of being gay. In 2021 to trans women were sent to prison for “wearing women’s clothing in a restaurant”.
In other words, we are talking about a complete shit-hole country and a non-negligible part of the cryptographic community cannot safely visit the conference because of that.
A conference that proudly associates itself with the #IACR. I think we should have a serious discussion about whether it is appropriate to place conferences in places that will imprison people for who they are and whether the IACR should associate with conferences that ignore these concerns.
For all the problems that conferences in the west have with accessibility (and that you may rightfully criticize), you can usually at least be confident that the government there won’t subject you to torture for who you are.
Nice analysis by Bruno Blanchet that proves that HPKE with ML-KEM (or any other IND-CCA2 KEM) does provide IND-CCA2 security.
“Bruno models the base mode of HPKE, single shot API in CryptoVerif, and showed that if the KEM is IND-CCA2, then so is HPKE.
Since CryptoVerif is PQ-sound, that proves the security of the HPKE base mode, with the single shot API when the KEM is a post-quantum IND-CCA2 KEM.” via Karthikeyan Bhargavan on the CFRG mailing list
🆕 blog! “Lazy way to cause SHA-256 collisions for lazy evaluators”
Humans are lazy. That's why we have computers; to do the boring work for us. I recently downloaded a file. The website said the file should have a SHA-256 hash of: ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb So I ran sha256 filename on my machine. And then lazily compared the h…
Join us for welcoming returning presenter Sergi Rovira, with Axel Mertens, from Universitat Pompeu Fabra (UPF) and @CosicBe respectively, presenting Convolution-friendly Image Compression in FHE, Apr 25th, 2024 @ 4PM CEST.
if you want to help people access the full, uncensored internet via Tor, and you're a fedi admin, here's a way you can help. you may know about Tor Bridges and how they're used by people behind repressive governments that censor the internet to safely access the net. countries like China or Russia block the public list of Tor relays, for example.
WebTunnel is a Bridge method that uses a reverse proxy that you configure using your existing nginx (etc) web server that points to your server's local tor daemon. so your fedi instance can be a bridge to the Tor network for people who cannot connect to Tor normally. disobey.net is hosting one ^^
one thing to note is that it's important to disable nginx (etc) web server logs, since the people who use bridges are connecting to you as their first, trusted hop onto the tor network. something to keep in mind to maximize privacy and reduce your own liability.
The tech, simply put, works like this: When you create an account for a website or app, your device generates a cryptographic public-private key pair. The site or app backend gets a copy of the public key, and your device keeps hold of the private key; that private key stays private to your gear. When you come to login, your device and the backend authentication system interact using their digital keys to prove you are who you say you are, and you get to login. If you don't have the private key or can't prove you have it, you can't login.
I did two different layouts of the backplane for my #Enigma-E metal case, just in case I get either of the two variants of the PP3 battery housing. This way, I can switch between using a small power supply or a 9V battery. 👍
There are 16 days left on the #Cybersecurity 2024 eBook bundle from Packt Publishing and Humble Bundle. Pay $18 or more for 23 titles. Pay less for 7 or 3 books.
🔐 OpenSSH Announces Plan to Phase Out DSA Keys
ᐅ @linuxiac
「 Its limitations have long been recognized, particularly its restriction to a 160-bit private key and reliance on the SHA1 digest.
These constraints render its security level equivalent to less than or equal to 80 bits in symmetric encryption, a standard considered insufficient in the current cybersecurity landscape 」
B) Chinese officials are exploiting the unfixed #vulnerability in the Apple AirDrop reported by #tudarmstadt researches in 2021 (disclosed to Apple in 2019) (*)
"In 2008, decades after her death, the files were finally declassified. If we could miss something as big as Elizabeth, who is crucial in two world wars, who fights crime, who fights the mob, if we missed her, who else are we missing?"
After sharing a link to Deirdre’s blog in a few places, several friendly folk expressed confusion about KEMs in general.
So very briefly, here’s an introduction to Key Encapsulation Mechanisms in general, to serve as a supplementary resource for any future discussion on KEMs.
You shouldn’t need to understand lattices or number theory, or even how to read a mathematics paper, to understand this stuff.
For the moment, let’s suspend most real-world security risks and focus on a simplified, ideal setting.
To begin with, you need some kind of Asymmetric Encryption.
Asymmetric Encryption means, “Encrypt some data with a Public Key, then Decrypt the ciphertext with a Secret Key.” You don’t need to know, or even care, about how it works at the moment.
Your mental model for asymmetric encryption and decryption should look like this:
Using asymmetric encryption safely means using it to exchange a key used for symmetric data encryption, like so:
// Alice sends an encrypted key to BobsymmetricKey = randomBytes(32)sendToBob = AsymmetricEncryption.encrypt( bobPublicKey, symmetricKey)// Bob decrypts the encrypted key from Alicedecrypted = AsymmetricEncryption.decrypt( bobSecretKey, sendToBob)assert(decrypted == symmetricKey) // true
You can then use symmetricKey to encrypt your actual messages and, unless something else goes wrong, only the other party can read them. Hooray!
And, ideally, this is where the story would end. Asymmetric encryption is cool. Don’t look at the scroll bar.
The real world isn’t as nice as our previous imagination.
We just kind of hand-waved that asymmetric encryption is a thing that happens, without further examination. It turns out, you have to examine further in order to be secure.
The most common asymmetric encryption algorithm deployed on the Internet as of February 2024 is called RSA. It involves Number Theory. You can learn all about it from other articles if you’re curious. I’m only going to describe the essential facts here.
Keep in mind, the primary motivation for KEMs comes from post-quantum cryptography, not RSA.
RSA is what we call a “trapdoor permutation”: It’s easy to compute encryption (one way), but decrypting is only easy if you have the correct secret key (the other way).
RSA operates on large blocks, related to the size of the public key. For example: 2048-bit RSA public keys operate on 2048-bit messages.
Encrypting with RSA involves exponents. The base of these exponents is your message. The outcome of the exponent operation is reduced, using the modulus operator, by the public key.
(The correct terminology is actually slightly different, but we’re aiming for intuition, not technical precision. Your public key is both the large modulus and exponent used for encryption. Don’t worry about it for the moment.)
If you have a very short message, and a tiny exponent (say, 3), you don’t need the secret key to decrypt it. You can just take the cube-root of the ciphertext and recover the message!
That’s obviously not very good!
To prevent this very trivial weakness, cryptographers proposed standardized padding schemes to ensure that the output of the exponentiation is always larger than the public key. (We say, “it must wrap the modulus”.)
The most common padding mode is called PKCS#1 v1.5 padding. Almost everything that implements RSA uses this padding scheme. It’s also been publicly known to be insecure since 1998.
The other padding mode, which you should be using (if you even use RSA at all) is called OAEP. However, even OAEP isn’t fool proof: If you don’t implement it in constant-time, your application will be vulnerable to a slightly different attack.
This Padding Stinks; Can We Dispense Of It?
It turns out, yes, we can. Safely, too!
We need to change our relationship with our asymmetric encryption primitive.
Instead of encrypting the secret we actually want to use, let’s just encrypt some very large random value.
Then we can use the result with a Key Derivation Function (which you can think of, for the moment, like a hash function) to derive a symmetric encryption key.
class OversimplifiedKEM { function encaps(pk: CryptoKey) { let N = pk.getModulus() let r = randomNumber(1, N-1) let c = AsymmetricEncryption.encrypt(pk, r) return [c, kdf(r)] } function decaps(sk: CryptoKey, c: Uint8Array) { let r2 = AsymmetricEncryption.decrypt(sk, c) return kdf(r2) }}
In the pseudocode above, the actual asymmetric encryption primitive doesn’t involve any sort of padding mode. It’s textbook RSA, or equivalent.
KEMs are generally constructed somewhat like this, but they’re all different in their own special, nuanced ways. Some will look like what I sketched out, others will look subtly different.
Understanding that KEMs are a construction on top of asymmetric encryption is critical to understanding them.
It’s just a slight departure from asymmetric encryption as most developers intuit it.
The one thing to keep in mind: While this transition from Asymmetric Encryption (also known as “Public Key Encryption”) to a Key Encapsulation Mechanism is easy to follow, the story isn’t as simple as “it lets you skip padding”. That’s an RSA specific implementation detail for this specific path into KEMs.
The main thing you get out of KEMs is IND-CCA security, even when the underlying PKE mechanism doesn’t offer that property.
What Are You Feeding That Thing?
Deirdre’s blog post touched on a bunch of formal security properties for KEMs, which have names like X-BIND-K-PK.
Most of this has to deal with, “What exactly gets hashed in the KEM construction at the KDF step?”
For example, from the pseudocode in the previous section, it’s more secure to not only hash r, but also c and pk, and any other relevant transcript data.
class BetterKEM { function encaps(pk: CryptoKey) { let N = pk.getModulus() let r = randomNumber(1, N-1) let c = AsymmetricEncryption.encrypt(pk, r) return [c, kdf(pk, c, r)] } function decaps(sk: CryptoKey, c: Uint8Array) { let pk = sk.getPublickey() let r2 = AsymmetricEncryption.decrypt(sk, c) return kdf(pk, c, r2) }}
In this example, BetterKem is greatly more secure than OversimplifiedKEM, for reasons that have nothing to do with the underlying asymmetric primitive. The thing it does better is commit more of its context into the KDF step, which means that there’s less pliability given to attackers while still targeting the same KDF output.
If you think about KDFs like you do hash functions (which they’re usually built with), changing any of the values in the transcript will trigger the avalanche effect: The resulting calculation, which is not directly transmitted, is practically indistinguishable from random bytes. This is annoying to try to attack–even with collision attack strategies (birthday collision, Pollard’s rho, etc.).
However, if your hash function is very slow (i.e., SHA3-256), you might be worried about the extra computation and energy expenditure, especially if you’re working with larger keys.
Specifically, the size of keys you get from ML-KEM or other lattice-based cryptography.
That’s where X-Wing is actually very clever: It combines X25519 and ML-KEM-768 in such a way that binds the output to both keys without requiring the additional bytes of ML-KEM-768 ciphertext or public key.
However, it’s only secure to use it this way because of the specific properties of ML-KEM and X25519.
Some questions may come to mind:
Does this additional performance hit actually matter, though?
Would a general purpose KEM combiner be better than one that’s specially tailored to the primitives it uses?
Is it secure to simply concatenate the output of multiple asymmetric operations to feed into a single KDF, or should a more specialized KDF be defined for this purpose?
KEMs aren’t nearly as arcane or unapproachable as you may suspect. You don’t really even need to know any of the mathematics to understand them, though it certainly does help.
Difficult is a cult centered around the exchange of Diffie–Hellman public keys. Its members are primarily known for their interest in obscure cryptographic inventions.
No, LLMs already have an acronym that's just three letters/syllables. The only reason you'd use "AI" to refer to an LLM is to misrepresent it as being more general than it is and I'm not interested in helping grifters by propagating that deception.