Something that I'm missing from both the article and the comments - I would remap the sleep button to F4 at OS level. Repeat analogous steps for other keys.
Granted, you'll lose these functions, and likely switching to another keyboard will drive you mad, but I guess this is a good stopgap software based solution.
This doesn't disagree with the poster above: they're saying that taking liability is a sign of belief in AGI. You're saying that lack of liability doesn't mean there's no AGI. Logically these two are not exclusive. p => q doesn't mean q => p.
Sorry, but these companies spend much more effort on making sure their product is walled off and incompatible with everything than giving it any actual quality.
You think Whatsapp for example is this lightweight and easy to use on basically any phone because no one spent a dime on some R&D on how to make it the way it is?
I am not well versed in Android or iPhone software development, but yes, I don't believe that making a non-bloated mobile app is pushing the frontier of software engineering.
There could be some arguments made somewhere as to where R&D money could go, perhaps somewhere in the backbone that billions could use, but the UI is not it.
All that said, I don't know how it furthers your initial argument exactly, as the DMA "beneficiaries" benefit from this lightweightness in zero percent. If anything, it's a negative, because one could assume they have to do better than that with what they're offering.
The company is very small, and they're doing a lot with what they have. Steam alone is full of arcane features that I keep discovering. There's a lot of backend stuff. They're making games and hardware.
Perhaps some of this is contracted, similar to the Linux compat and drivers, but it's still impressive to me, compared to the orgs like Spotify, order of magnitude larger with barely any features at all. (I understand there's legal, huge backend, and I didn't see many bugs over time, but still)
But would it actually help. More employees means more communication and overhead. Lean organisations can move much quicker. Part of why valve can do what valve does is how lean it runs.
It seems to me you assumed that the poster that replied to you meant encrypting in parallel, while it seems pretty clear to me what they meant was c = E1(E2(p, k2), k1).
The thing is: Quantum computers don't break AES-GCM, ChaCha20-Poly1305, or any other modern authenticated cipher. Layering encryption or doing cipher cascades is pointless.
The thing a cryptography-relevant quantum computer does is break RSA and elliptic curve cryptography, so that the underlying key (k1 or k2) is recoverable from its corresponding public component.
Hybrid KEMs, such as mlkem768x25519 (a.k.a. X-Wing) is a simple abstraction with security proofs that does both classical (X25519 is elliptic curve) and post-quantum (ML-KEM-768 is lattice-based) cryptography and combines them securely into a single key agreement.
"Encrypt twice" is bad advice. Even if you get the same approximate security, you're giving up a lot of performance.
Encrypt once, but encrypt with a key you can be confident in the secrecy of.
Are you saying that a "hybrid KEM" is different in theoretical risk from chaining two KEMs? The change of jargon from "encryption" to "KEM" doesn't mean anything to most people talking about this post-quantum risk. To the extent we know what KEM is, we think it is just encrypting the key used for the rest of the bulk encryption.
Whether or not people understand the nuance of encrypting the block cipher keys or encrypting the blocks themselves, I think we all mean to stack the two encryption methods for defense-in-depth protection. They intuit having to open two locks in series to get to the valuable stuff, not adding two different access paths that each suffice for access.
"Intuition" about how cryptography works is notoriously bad. Many intuitive things about cryptography are false, and many true things about cryptography are non-intuitive. For this reason it is difficult to seriously discuss cryptography when people are vaguely referring to what they intuitively hope to achieve, framed in terms of concrete constructions that are not secure.
This is also completely ignoring that designing secure systems is about MUCH more than selecting the right "hard problem". Concretely
> They intuit having to open two locks in series to get to the valuable stuff, not adding two different access paths that each suffice for access.
might mean requiring a much more complicated lock that, in its ideal implementation has the properties you want, but practically is easier to implement incorrectly, yielding a less secure scheme. Considerations of this form almost never appear, despite being very relevant to the end goal of protecting users.
Similarly, this "defense in depth" intuition is currently not particularly controversial for hybrid KEMs. it is currently quite controversial for hybrid signatures though. The intuitive story would work perfectly well for signatures though. So this intuition does not end up being particularly useful for understanding the actual discussion.
I don't disagree, but I think the folks who know this ought to remember the lay person perspective and try to address it more concretely.
Rather than rejecting the framing because they (we) aren't fluent in your jargon, provide a more constructive hint... E.g. "You may be thinking the symmetric cipher key is simply encrypted with the asymmetric cipher and concatenated to the bulk message. But, to mitigate known cryptographic system risks, modern solutions use specialized key encapsulation or key exchange methods (KEM) which are not directly encrypted messages containing key material."
> I think the folks who know this ought to remember the lay person perspective
That's fair. I hold Hacker News to a higher bar of technical proficiency than a general audience. My hope with insisting on correct framing is to nudge other experts in adjacent fields to teach your more general audiences how to think about these topics more correctly so it's more approachable to the general public.
I'm generally sympathetic to your point, it is just difficult for this particular topic. For example, I mentioned how precision in cryptographic language is important, as there was a discussion about combiners for encryption, when really people should use combiners for KEMs, along with hybrid encryption (here, meaning building public-key encryption from a KEM + symmetric key encryption).
The issue is that none of the above is relevant to the article that we are in the comments of. The article is about signatures. Why are we talking about encryption/KEMs in the first place?
One might hope the story for combiners for KEMs (which people may have intuition for due to combiners for encryption, which you could easily show in an undergraduate cryptography course) is broadly similar to the story for combiners for signatures. Unfortunately, that's not true at all. It would be a very reasonable perspective to have that we should use combiners for KEMs but not combiners for signatures. It would be very difficult to communicate this to a layperson without being very precise about the jargon.
This is especially true as this is a topic where a notable cryptographer has spent the last few years libeling several other cryptographers, and spreading a good deal of misinformation to laypeople. He is also extremely litigious, and has either sued or threatened to sue several cryptographers for what I view to be nonsense reasons. For some (at least myself), this makes precise language all the more important in topics he might have his eyes on.
So I both broadly agree with you for most topics, and also this particular topic requires a good deal more precision than most others in cryptography.
> Are you saying that a "hybrid KEM" is different in theoretical risk from chaining two KEMs?
No, I'm saying that "hybrid KEM" or "chaining two KEMs" is very distinct from "encrypt twice". Confuse the two at your own peril.
> To the extent we know what KEM is, we think it is just encrypting the key used for the rest of the bulk encryption.
Encryption is reversible. If you have the key, you can decrypt. It's not encryption if you can't decrypt.
KEMs are their own class of algorithms. They combine an asymmetric encryption scheme with an all-or-nothing one-way transform (usually a key derivation function built on hash functions). It's the safest way to hold asymmetric encryption in practice (even not considering PQ; RSA-KEM beats RSA-OAEP in implementation safety).
Calling KEMs "encryption" is misleading to the point of malpractice. I will push back on conflating the two.
> Whether or not people understand the nuance of encrypting the block cipher keys or encrypting the blocks themselves, I think we all mean to stack the two encryption methods for defense-in-depth protection.
Your only defense-in-depth should be in delivering a strong pseudorandom ephemeral key over an untrusted network, and then using the tried-and-true AEAD constructions that we're already using today. Encrypt once. Do whatever you need to do to get the key exchanged securely.
I write a blog that very regularly covers applied cryptography. I deal with newbie confusion all the time. It's very important that we talk about these things correctly on forums like Hacker News comment threads so that the people learning from us won't get more confused.
both encrypting in parallel and encrypting in the second way you mentioned are bad ideas, and are far from being what is seriously being discussed when people talk about hybrid KEMs. Encrypting in parallel is explicitly IND-CPA insecure if one of the ciphers is broken. Your construction is IND-CPA secure, but quite inefficient, and would not fit into modern protocols.
If this was a typical cryptographic topic, this might be fine, and is how I would likely phrase things for an undergraduate cryptography course. Unfortunately, this is a topic that a certain cryptographer with a decently large public following has been spreading conspiracy theories (and slandering other cryptographers about) for a number of years now. So, discussions on this topic often come from a place where the audience is misinformed, and more care is required in grounding the discussing in what is actually being discussed/considered.
I guess from my perspective there are even more dire problems in the US that I'm surprised people accept. But it seems they don't know, or care, or know that they should care.
Perhaps it's the lack of proper authoritarian regime in the US' past that drives this. I believe the temporal proximity of such makes people aware of, and angry against, the many traps that such systems leave in their "law", so you can be imprisoned anytime for anything. EU has a bunch of countries with varying degree of such past.
Most people need to work to support themselves so it's quite inconvenient to single-handedly solve all of the problems in the US. Suggesting people simply don't know or care is very naive.
I’m sympathetic to this view, butI don’t see any evidence they actually do know or care though. This (workers rights) gains no traction in US elections. You have this weird macho culture around it, almost like complaining about this abuse would be a sign of personal weakness.
RAM disk is, like, the brd module on Linux, which allocates and exposes a /dev/ram0 block device.
From the project description this looks like it, exposing a raw block device backed by VRAM (with some trip through the nbd protocol, but that's an implementation detail to have it in userland, it could just as well have been implemented kernel side).
It's just that the usage of this mem-backed block device is different than the thing of yore (copy HD or floppy into RAM)
The more frequent alternative to brd, tmpfs, skips the block device part and does a filesystem directly. I wonder if it could be made so that it's swap directly and skip the block device part entirely like tmpfs.
It's _badly intentioned_ (and not just UI). Blackmailing you with losing labelling, which worked fine before all that is a clear proof. So "malware" is not really so far off the point.
Feature A exists for years. New feature B enters. If you want to opt out of feature B, you now need to opt out of feature A as well, which you probably liked much more.
I don't know a better term than blackmail to describe this. Thesaurus seems to imply blackmail is for money, but so is extortion, and it doesn't give me good suggestions.
EDIT: Coercion is more correct, but it's way too mild in my perception.
Granted, you'll lose these functions, and likely switching to another keyboard will drive you mad, but I guess this is a good stopgap software based solution.
reply