Bikeshedding while the world burns

[rca]

I convinced some of my co-workers to use GPG, we have been using it to 
secure some emails/Whatsapp messages, but your email got me thinking 
about keyloggers. Are there some security recommendations to stay safe 
from it?

Ricardo


On 4/28/26 00:37, Robert J. Hansen via Gnupg-users wrote:
> 1. INTRODUCTION
> 
> Around 1997, Sun Microsystems hauled Microsoft in court over the Java 
> virtual machine (JVM) Microsoft was shipping with new versions of 
> Windows. Microsoft had entered an agreement with Sun to ship a JVM that 
> fully complied with Sun's compatibility tests, but they failed to honor 
> this promise. They insisted they were doing the right thing for their 
> users, which may have well been true -- but "best for our users" was not 
> the same as "best for Java users".
> 
> I'm told that after Microsoft lost this lawsuit they decided to embrace 
> C# and the Common Language Runtime as sort of a "Java that we control." 
> Java and C# started off as very similar languages but drifted apart over 
> time; likewise with their virtual machines.
> 
> I am afraid GnuPG is soon going to be a retelling of this story.
> 
> I downloaded GnuPG 1.0 the day it was released. I was at the time 
> writing an RFC1991 ("ClassicPGP") implementation for a now-defunct 
> telecom that had very strange ideas about why PGP 2.6 exposed them to 
> legal liability, and I wanted to see how GnuPG implemented some packet 
> parsing magic. At that time GnuPG's mission statement was crystal clear: 
> to provide a libre command-line implementation of the RFC2440 standard.
> 
> For a quarter-century GnuPG has been the gold standard of OpenPGP 
> implementations and 100% libre software. This is an amazing achievement, 
> and I think Werner deserves immense accolades for his persistence and 
> determination in achieving this vision.
> 
> But I think we're heading down the wrong road by turning away from the RFC.
> 
> 2. THE COLD TRUTH
> 
> You could replace RFC9580 with RFC1991 from thirty years ago and still 
> be sufficient for many users.
> 
> Seriously. Most users don't need 30-year security, they need 10-year 
> security at the outside, for secrets that are relatively low value 
> (under $1 million). RSA-1024 still looks solid for that time window. It 
> might be possible to break an RSA-1024 key today, but not for a million 
> dollars.
> 
> A lot of users don't care very much about signatures, either. They care 
> a lot about the confidentiality of their email: the authenticity takes a 
> back seat. MD5 matters a lot less.
> 
> RFC1991 used a single key for authentication and encryption. This meant 
> trouble if a user was ever compelled by a court to reveal their 
> decryption key. That was a major motivator of RFC2440, and yet it turns 
> out compelled turnover of an asymmetric encryption key is incredibly 
> rare: it happens so infrequently it might as well not happen.
> 
> Over the last thirty years the IETF working group leading RFC design has 
> invented an ever-more-impregnable bank vault door, even as the building 
> that bank vault is installed in (operating systems and environments) 
> have become ever shoddier.
> 
> In my mind, the LibrePGP versus OpenPGP technical arguments are about as 
> interesting to me as arguing whether a meter-thick tempered steel vault 
> door that laughs in the face of explosives, diamond-tipped drill bits, 
> and antitank rockets is secure enough, or whether we need to also have a 
> Belgian malinois watching things.
> 
> Please don't think, "oh, Rob doesn't understand the specifications, 
> that's why he's saying these differences don't matter". I _do_ 
> understand the specifications. I don't influence the specs. I never said 
> I didn't read them or have opinions on them.
> 
> Here's the truth: I love Belgian malinois. After German shepherds 
> they're my favorite breed. They're a little too energetic and high- 
> strung for me to ever own one, but I adore them. I also don't care if my 
> vault door is guarded by one.
> 
> 3. THE REAL RISK
> 
> The real risk today is endpoint compromise. It's cheap, it's easy, it's 
> fun.
> 
> Many years ago a divorce attorney came to me with a problem: his client 
> was divorcing her husband. They lived in separate apartments since the 
> divorce petition was filed. She had reason to believe he was lying about 
> his assets but had no way to check on his bank accounts without his 
> knowledge. Was there any way I could help?
> 
> After confirming they lived in a marital joint property state (where, 
> until the time a divorce is finalized, all property in the marriage is 
> owned by both), I agreed to do the job. The woman wrote a letter 
> authorizing me to enter her husband's apartment to look for financial 
> records, and I filed this with my attorney.
> 
> I showed up at his apartment after he left for work, picked the lock, 
> walked into his office and started taking photographs so I could leave 
> the place in the exact same state as when I left. I made a forensic 
> image of his hard drive, connected a keylogger, and left. I returned the 
> next day to pick up the keylogger.
> 
> All of his online security measures -- only using HTTPS through a VPN, 
> using Bitlocker, not using a password manager, etcetera -- vanished in 
> about a day the moment a semi-skilled attacker decided to go after the 
> endpoint. Even Bitlocker fails when the enemy has a forensic image of 
> your hard drive and, thanks to a keylogger, your BitLocker password.
> 
> Had he shared his apartment with a Belgian malinois, I would have been 
> deterred. But neither a cryptographic vault door nor a cryptographic 
> Belgian malinois proved any obstacle whatsoever.
> 
> 4. MORE ON ENDPOINTS
> 
> Physical endpoint compromise, like what I describe above, is the 
> ultimate game over condition. Network endpoint compromise is almost as bad.
> 
> The network landscape in 2026 is not what it was in 1996. There is no 
> longer any meaningful concept of a secure network perimeter. In the 
> cyberwarfare trade the Internet of Things is instead called the 
> "Internet of Targets".
> 
> Here in Washington D.C., it's widely believed the Chinese government, 
> through a cyberwarfare program called SALT TYPHOON, has at-will access 
> to any smartphone it wants in the metropolitan area. (This may be 
> revenge of a kind: Edward Snowden revealed to them the NSA had at-will 
> access to any text message in Hong Kong.)
> 
> My apartment building has decided my front door should no longer have a 
> physical key, but instead be locked and unlocked from my smartphone. My 
> bank encourages me to do all my banking via an app. Local hotels do the 
> same thing.
> 
> The endpoints are already compromised, and we're ...
> 
> ... arguing about whether we need a Belgian malinois _and_ a meter-thick 
> tempered steel vault door?!
> 
> 5. C# AND JAVA, REDUX
> 
> When Microsoft was told the Java spec was what it was and wouldn't be 
> changed to accommodate them and their users' needs, Microsoft made a 
> wise call. They walked away and made a clean break. Over time C# has 
> become its own thing and a vastly different ecosystem compared to Java.
> 
> I would very much like GnuPG to decide either to:
> 
>      (a) implement RFC9580 in GnuPG, even if it's not enabled
>          by default
>      (b) make a clean break from RFC9580 and go on to solve a
>          similar-but-different set of problems a similar-but-
>          different way
> 
> I don't care which is done but I really think we need to do one or the 
> other.
> 
> This community is suffering, *badly*, because people are arguing over 
> the presence of a Belgian malinois. We should stop the bleeding, even if 
> the tourniquet hurts.
> 
> 6. AM I LEAVING THE COMMUNITY?
> 
> Of course not. That would be silly. I love this community too much for 
> that.
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users