Isn't RSA the current secure solution for the corresponding encryption/security on the browser with JavaScript?
»Galois/Counter Mode and random nonces:
It turns out you can encrypt more than 2^32 messages with AES-GCM with a random nonce under certain conditions. It’s still not a good idea, but you can just about do it.«
Something else I’ve noticed at #rsa this year is a lack of red. A lot of orange, pink and purple and blue, but not a lot of red, much less than previous years. (do not underestimate color impact when it comes to marketing and sales.) #rsac#rsac2024
Another change I have noticed at #rsa is a lot of older established companies opting for the smaller booths in the N/S connector this year. And then, of course, there are the new upstarts with way too much VC getting a booth that’s way too big for them, that hasn’t changed and probably never will. #rsac#rsac2024
Pour mettre les allocataires du RSA au travail, le Nord choisit un coûteux contrat à impact social
Fin 2023, le conseil départemental a signé un contrat à 4,5 millions visant à réinsérer les autoentrepreneurs allocataires du #RSA. La puissance publique recourt à des investisseurs privés pour financer l’action sociale, avant de les rembourser avec intérêts. Mediapart publie cette fructueuse convention.
Il réagira comment, le gouvernement, quand il constatera que les heures de bénévolat forcé des titulaires du #RSA servent à fabriquer des banderoles et des tracts, écrire des manifestes, créer les slogans et aller manifester pour les #doitssociaux qu'il tente de détruire ?
A Backdoor in XZ Utils was found!
To know if you are affected rune:
xz -V in your terminal
if like me you have XZ 5.6.0 or XZ 5.6.1 downgrade XZ Utils to an earlier version, such as 5.4.6 (Stable) or disable ssh
To all who are hosting their own #dns#authoritive server with #dnssec - what do you use in 2024?
#Ed25519 or #ECDSA-P256 or still on some #RSA algorithms? Shorter key length is especially in DNS a benefit but still not all resolvers may be able to support this in 2024?!
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.
Dussopt en a marre des sujets sur le RSA, le chômage et les retraites. Redevenu simple député et toujours menacé par la justice (le parquet a fait méchamment appel de sa relaxe pour favoritisme), l'ex-ministre s'intéresse aux "énormes enjeux économiques de l’industrie de défense", selon Les Echos. C'est plus rémunérateur que les pauvres...
Conditionnement du RSA : Bardella « parfaitement d'accord » avec Macron
RSA. Le vernis du RN a craqué une nouvelle fois ce week-end. Invité de l’émission « Dimanche en politique » le 4 février 2024, Jordan Bardella a affirmé être « parfaitement d’accord » avec le conditionnement du RSA à 15 heures « d’activité », défendu par Emmanuel Macron et Gabriel Attal. Autrement dit, au travail forcé pour espérer obtenir la bagatelle que constitue le RSA.« Je pense qu’il faut des contreparties aux prestations sociales de ce type qui sont versées », a expliqué le président du parti d’extrême droite. https://linsoumission.fr/2024/02/08/bardella-reforme-rsa-rn-bardella/ #RSA #RN#BardellaFacho #linsoumission #LFI
Anyone in #Fife know of a good person with a Van to help my daughter transport some paintings to the #Edinburgh#RSA in March, she's thinking about just taking the train but some of these pieces are 1.5m across so I'm thinking it's not the best idea.
Massacre social en vue: Gabriel Attal annonce la généralisation du dispositif de conditionnement du RSA à "15H d'activité pour l'insertion" à tous les départements de France. La généralisation du travail gratuit pour les pauvres, mais quelle honte!
The perceived RSA-3000 crypto mandate by the German Federal Office for Information Security (BSI) has been reported by @heiseonline highlighting that:
💡 a BSI speaker confirmed that this is a recommendation, not a mandate
💡 the TLS certificate of the #BSI website still uses RSA-2048 as well
💡 the wording, especially across BSI publications, is confusing and could be misleading
This reporting¹ is in the context of TLS (publications TR-02102-2, TR-03116-4), but the same issues are present with the general "Technische Richtlinien" document on cryptographic algorithms and key lengths (TR-02102 part 1), which is cited by sources like keylength.org, often without the nuance from the preamble, such as:
👩🏻⚖️ the recommendations do not preempt regulatory approval processes
🧑🏻💻 they target developers planning new systems
💫 they may exceed the stated goal of achieving 120 bits of security
The Heise article¹ concludes that "A #signature algorithm for TLS needs to be secure for only as long as the certificate is valid, which is typically one year." It also notes that the US National Institute of Standards and Technology (NIST) "considers #RSA with a key length of 2048 bits to be sufficiently secure for signatures until the year 2030".