4 ms·

Why can’t they know when someone uses the secret keys? Perhaps the messages would be individually encrypted and the keys would need to be used in order to retr

by EGreg 3y ago

Why can’t they know when someone uses the secret keys? Perhaps the messages would be individually encrypted and the keys would need to be used in order to retrieve the message encryption keys. And to do this, they would need to provide an explicit reason and only get the limited info that the warrants etc. would support and the reasons would be stated in every case.

pavel_lishin 3y ago
> And to do this, they would need to provide an explicit reason and only get the limited info that the warrants etc. would support and the reasons would be stated in every case. The scenario I'm talking about isn't overly-broad warrants, etc. Technology can't prevent that. I'm talking about just the tech implementation. Fine, we have a private keypair for every message, and every message is additionally encrypted with the public key of the government-per-message-keypair. How are these per-message keypairs generated? If from a central server, then that becomes a massive weakpoint in the system for multiple reasons: it could be attacked to prevent new keypairs from being generated, it could be hacked to extract private keys, it could be modified to generate keypairs that an adversary can easily break, it could be modified to also send private keys to adversaries, etc., etc. If they're generated on-client, and the secret key is sent to some central repository, then the client or the device the client is running on could be compromised; the private keypairs could be intercepted en-route; the central repository could _still_ be compromised since it can't be airgapped to receive these keypairs. In the case of a warrant, how is each key actually fetched? I don't mean the legal process, I mean at some point someone has to push a button and decrypt a message. How do we protect that process? Besides the fact that even air-gapped systems can be vulnerable to a sufficiently motivated and well-funded adversary, at some point some human being has to have access to this system, and that human being probably has family members. How vulnerable are they to being beaten with rubber hoses, or receiving their spouse's fingers in the mail? If you're going to build a system that can expose everyone's private communications, it better be incredibly close to fool-proof, or it better not be built at all.
DexesTTP 3y ago
The point is that today, the key isn't in Google's or Amazon's or Meta's servers, but on the phones of people. That means that you literally don't have the key if you don't have the phone. And governments don't want that, they want the keys in order to eavesdrop but without being noticed (and stealing the phone would get you noticed). So your only option to comply with this is to remove the phone-only key storage option and move all of the key into your servers, which is what we talk about when we mean "breaking end-to-end encryption". The issue is that to comply with the rules, you have to secure that server so only the good guys can get in, and only if the warrant is legit, but also to allow fast access for time-sensitive cases such as terrorism and secret cases such as NSA investigations. You also have to make sure that there's absolutely no way for people to access that server if they don't have the approval. Oh, and also that server / these servers contain the keys to read every message from every citizen of your country (including politicians), which is probably worth as much of your GDP. So you need to build the equivalent of a safe containing one trillion dollars that can't be accessed for any reason except all of the reasons mentioned abov3. Except that this theoretical trillion of dollars are special dollars where if you mess up and let people in without anyone noticing they got in, they can "steal" the trillion dollars and start spending them and nobody would notice that they're being spent. And there's just about every country on earth that would love to "borrow" your two trillion dollars, especially if you can't ever realistically prove they did it. Easy, right?
- ethbr1 3y ago
  Has there ever been a public key sign-countersign encrypted tap method? I.e. Authorized tap requestors have keys (law enforcement, intelligence) and sign a request (including timestamp), storing a copy for audit. The approval system (courts, FISA) validates that request, countersigns if they approve (including timestamp), storing a copy for audit. The system owners (messaging services, etc.) then validate both signatures and provide the requested tap information, creating a tap record (including content scope and timestamp), storing a copy for audit. Ideally, then all audit logs get publicly published, albeit redacted as needed for case purposes. Part of the central issue is deciding "Who should be responsible for security?" Imho, if governments want to mandate a scheme like this, it sure as shit shouldn't be the tech companies. The government should have to manage its own keys, or deal with consequences of leaking them (while allowing the tech companies to retain independent records of individual requests). As much as it pains me to say this... this wouldn't be the worst use case for a blockchain...

by EGreg 3y ago

pavel_lishin 3y ago

> And to do this, they would need to provide an explicit reason and only get the limited info that the warrants etc. would support and the reasons would be stated in every case. The scenario I'm talking about isn't overly-broad warrants, etc. Technology can't prevent that. I'm talking about just the tech implementation. Fine, we have a private keypair for every message, and every message is additionally encrypted with the public key of the government-per-message-keypair. How are these per-message keypairs generated? If from a central server, then that becomes a massive weakpoint in the system for multiple reasons: it could be attacked to prevent new keypairs from being generated, it could be hacked to extract private keys, it could be modified to generate keypairs that an adversary can easily break, it could be modified to also send private keys to adversaries, etc., etc. If they're generated on-client, and the secret key is sent to some central repository, then the client or the device the client is running on could be compromised; the private keypairs could be intercepted en-route; the central repository could _still_ be compromised since it can't be airgapped to receive these keypairs. In the case of a warrant, how is each key actually fetched? I don't mean the legal process, I mean at some point someone has to push a button and decrypt a message. How do we protect that process? Besides the fact that even air-gapped systems can be vulnerable to a sufficiently motivated and well-funded adversary, at some point some human being has to have access to this system, and that human being probably has family members. How vulnerable are they to being beaten with rubber hoses, or receiving their spouse's fingers in the mail? If you're going to build a system that can expose everyone's private communications, it better be incredibly close to fool-proof, or it better not be built at all.

DexesTTP 3y ago

The point is that today, the key isn't in Google's or Amazon's or Meta's servers, but on the phones of people. That means that you literally don't have the key if you don't have the phone. And governments don't want that, they want the keys in order to eavesdrop but without being noticed (and stealing the phone would get you noticed). So your only option to comply with this is to remove the phone-only key storage option and move all of the key into your servers, which is what we talk about when we mean "breaking end-to-end encryption". The issue is that to comply with the rules, you have to secure that server so only the good guys can get in, and only if the warrant is legit, but also to allow fast access for time-sensitive cases such as terrorism and secret cases such as NSA investigations. You also have to make sure that there's absolutely no way for people to access that server if they don't have the approval. Oh, and also that server / these servers contain the keys to read every message from every citizen of your country (including politicians), which is probably worth as much of your GDP. So you need to build the equivalent of a safe containing one trillion dollars that can't be accessed for any reason except all of the reasons mentioned abov3. Except that this theoretical trillion of dollars are special dollars where if you mess up and let people in without anyone noticing they got in, they can "steal" the trillion dollars and start spending them and nobody would notice that they're being spent. And there's just about every country on earth that would love to "borrow" your two trillion dollars, especially if you can't ever realistically prove they did it. Easy, right?

ethbr1 3y ago
Has there ever been a public key sign-countersign encrypted tap method? I.e. Authorized tap requestors have keys (law enforcement, intelligence) and sign a request (including timestamp), storing a copy for audit. The approval system (courts, FISA) validates that request, countersigns if they approve (including timestamp), storing a copy for audit. The system owners (messaging services, etc.) then validate both signatures and provide the requested tap information, creating a tap record (including content scope and timestamp), storing a copy for audit. Ideally, then all audit logs get publicly published, albeit redacted as needed for case purposes. Part of the central issue is deciding "Who should be responsible for security?" Imho, if governments want to mandate a scheme like this, it sure as shit shouldn't be the tech companies. The government should have to manage its own keys, or deal with consequences of leaking them (while allowing the tech companies to retain independent records of individual requests). As much as it pains me to say this... this wouldn't be the worst use case for a blockchain...