I’ve never seen it stated as a requirement of the PGP protocol that it is impossible to hide extra information in a signature. In an ordinary use case this is not a security risk; it’s only a problem when the implementation is untrusted. I have as much disrespect as anyone towards people who think they can easily achieve what experts who spent years thinking about it can’t, but that’s not what is going on here.
Let’s assume you CAN leak arbitrary amounts of information into a PGP signature.
Short of somehow convincing the victim to send you a copy of their message, you have no means of accessing your recently-leaked data. And since that is extremely unlikely, your only hope is to view a public message the user posts with their compromised signature. Which leads to....
That leaked data would be publicly available. Anyone with knowledge of your scheme would also be able to access that data. Any encryption would be worthless because the encryption would take place client-side and all credentials thus would be exposed to the public as well. Which brings us to....
Because the script runs client-side, it also makes it extremely easy for a potential victim to examine your code to determine if it’s malicious or not. And, even if they’re too lazy to do so...
A private key is long. A PGP signature is short. So your victim’s compromised signature would be 10x longer than the length of a normal PGP signature.
So yes, you all are correct. If I had malicious intent, I could write an attack that 1. could be immediately exposed to the public by any person with programming knowledge, 2. provides an extremely obvious telltale sign to the victim that something malicious is going on, and 3. doesn’t actually provide me any benefit.
Short of somehow convincing the victim to send you a copy of their message, you have no means of accessing your recently-leaked data.
Public-key signatures should always be considered public when anticipating attacks. Use HMACs if you want secret authentication.
That leaked data would be publicly available. Anyone with knowledge of your scheme would also be able to access that data. Any encryption would be worthless because the encryption would take place client-side and all credentials thus would be exposed to the public as well.
You explicitly mentioned Decoy in your article, and a similar method could be used to leak bits to an attacker with no one else being able to recover them. We’re discussing public key encryption in this article which means that completely public javascript can indeed securely encrypt data using a public key and only the owner of the corresponding private key can decrypt it.
Because the script runs client-side, it also makes it extremely easy for a potential victim to examine your code to determine if it’s malicious or not. And, even if they’re too lazy to do so...
Sure, the first five or ten times it’s served. And then one time the victim reloads the page, the compromised script runs, leaks as much or all of the private key as possible, and then never gets served again.
A private key is long. A PGP signature is short. So your victim’s compromised signature would be 10x longer than the length of a normal PGP signature.
An exported private key is long because it includes both factors, the private exponent, and the inverse of p mod q. In my other comment I was too lazy to decode the key and extract one of the RSA factors, but one factor will be ~50% of the size of the RSA signature and that’s all an attacker needs.
Well shit. This is the third time I’ve had to re type this post so forgive the brevity.
You are right but it makes the attack less effective, since it’s a phishing attack not a targeted one. I can’t think of an efficient way for an attacker to collect these compromised signatures without making it even more obvious to the victim.
This is correct, you could asymmetrically encrypt the data.
The intended use is for the user to download the script and run it locally. Seving a compromised copy 10% of the time would just lower the reach of the attack. Especially cause the visitor can still verify the source code, or verify the output of the signature.
Even if you cut the size of the private key in half, the signature would still be 5x longer than a standard PGP signature, and the fact that subpacket 20 has been padded with a large amount of data would be immediately visible to the victim upon verifying their own signature. (Note that I didn’t include a verification tool, so the visitor would have to do that on their own trusted software.)
That leaked data would be publicly available. Anyone with knowledge of your scheme would also be able to access that data.
That’s often the case with backdoors.
Any encryption would be worthless because the encryption would take place client-side and all credentials thus would be exposed to the public as well.
Did you understand the point of private-public key crypto?
Because the script runs client-side, it also makes it extremely easy for a potential victim to examine your code to determine if it’s malicious or not. And, even if they’re too lazy to do so...
I doubt anyone would bother to examine the code to a sufficient level to find security flaws. Especially since the code seems a bit obfuscated.
How long did it take people to find out that Debian’s crypto was flawed? RSA?
A private key is long. A PGP signature is short. So your victim’s compromised signature would be 10x longer than the length of a normal PGP signature.
That just means that it takes 10 signed messages to leak all data. Maybe it bit more because you have to randomly pick one of 10 slots. Maybe a bit less because you can do fancy math.
At this point I am just going to cease replying to any of your posts because this discussion has become patently absurd. You have resorted to citing weaknesses that are common to any protocol that the user is too lazy to verify the safety of. What’s next? It’s unsafe because you might have a heart attack while using it?
Congratulations: you are the kid in the philosophy class that derails the conversation by asking “Yeah but how do we KNOW that?” over and over. Except the difference here is, I’m not being paid to, nor do I have the patience to walk you through the basics of security, trust, cryptography, etc.
Yes, I will concede that, given enough ignorance on the part of the user, it is possible to sneak a backdoor into any medium. Including this tool. Speaking of which, there’s a backdoor programmed into this post. If you send me a private message with your Less Wrong password, you’ll see it.
At this point I am just going to cease replying to any of your posts because this discussion has become patently absurd. You have resorted to citing weaknesses that are common to any protocol that the user is too lazy to verify the safety of.
The problem isn’t directly in the specific vunerability but that you produce a crypto program and make false claims about it.
It’s a standard for people who produce good crypto to care about vunerabilities of their software and don’t overstate the capabilities of their software.
I have the patience to walk you through the basics of security, trust, cryptography, etc.
Your understand of trust is so poor that you said that PGP would have be known to be flawed for the possibility for information to be transmitted as Pentashagon and me claimed.
Most people who want to hide a picture on their phone likely don’t need real security anyway so it’s not bad if you make a few errors here and there.
I’ve never seen it stated as a requirement of the PGP protocol that it is impossible to hide extra information in a signature. In an ordinary use case this is not a security risk; it’s only a problem when the implementation is untrusted. I have as much disrespect as anyone towards people who think they can easily achieve what experts who spent years thinking about it can’t, but that’s not what is going on here.
Let’s assume you CAN leak arbitrary amounts of information into a PGP signature.
Short of somehow convincing the victim to send you a copy of their message, you have no means of accessing your recently-leaked data. And since that is extremely unlikely, your only hope is to view a public message the user posts with their compromised signature. Which leads to....
That leaked data would be publicly available. Anyone with knowledge of your scheme would also be able to access that data. Any encryption would be worthless because the encryption would take place client-side and all credentials thus would be exposed to the public as well. Which brings us to....
Because the script runs client-side, it also makes it extremely easy for a potential victim to examine your code to determine if it’s malicious or not. And, even if they’re too lazy to do so...
A private key is long. A PGP signature is short. So your victim’s compromised signature would be 10x longer than the length of a normal PGP signature.
So yes, you all are correct. If I had malicious intent, I could write an attack that 1. could be immediately exposed to the public by any person with programming knowledge, 2. provides an extremely obvious telltale sign to the victim that something malicious is going on, and 3. doesn’t actually provide me any benefit.
Public-key signatures should always be considered public when anticipating attacks. Use HMACs if you want secret authentication.
You explicitly mentioned Decoy in your article, and a similar method could be used to leak bits to an attacker with no one else being able to recover them. We’re discussing public key encryption in this article which means that completely public javascript can indeed securely encrypt data using a public key and only the owner of the corresponding private key can decrypt it.
Sure, the first five or ten times it’s served. And then one time the victim reloads the page, the compromised script runs, leaks as much or all of the private key as possible, and then never gets served again.
An exported private key is long because it includes both factors, the private exponent, and the inverse of p mod q. In my other comment I was too lazy to decode the key and extract one of the RSA factors, but one factor will be ~50% of the size of the RSA signature and that’s all an attacker needs.
Well shit. This is the third time I’ve had to re type this post so forgive the brevity.
You are right but it makes the attack less effective, since it’s a phishing attack not a targeted one. I can’t think of an efficient way for an attacker to collect these compromised signatures without making it even more obvious to the victim.
This is correct, you could asymmetrically encrypt the data.
The intended use is for the user to download the script and run it locally. Seving a compromised copy 10% of the time would just lower the reach of the attack. Especially cause the visitor can still verify the source code, or verify the output of the signature.
Even if you cut the size of the private key in half, the signature would still be 5x longer than a standard PGP signature, and the fact that subpacket 20 has been padded with a large amount of data would be immediately visible to the victim upon verifying their own signature. (Note that I didn’t include a verification tool, so the visitor would have to do that on their own trusted software.)
That’s often the case with backdoors.
Did you understand the point of private-public key crypto?
I doubt anyone would bother to examine the code to a sufficient level to find security flaws. Especially since the code seems a bit obfuscated.
How long did it take people to find out that Debian’s crypto was flawed? RSA?
That just means that it takes 10 signed messages to leak all data. Maybe it bit more because you have to randomly pick one of 10 slots. Maybe a bit less because you can do fancy math.
At this point I am just going to cease replying to any of your posts because this discussion has become patently absurd. You have resorted to citing weaknesses that are common to any protocol that the user is too lazy to verify the safety of. What’s next? It’s unsafe because you might have a heart attack while using it?
Congratulations: you are the kid in the philosophy class that derails the conversation by asking “Yeah but how do we KNOW that?” over and over. Except the difference here is, I’m not being paid to, nor do I have the patience to walk you through the basics of security, trust, cryptography, etc.
Yes, I will concede that, given enough ignorance on the part of the user, it is possible to sneak a backdoor into any medium. Including this tool. Speaking of which, there’s a backdoor programmed into this post. If you send me a private message with your Less Wrong password, you’ll see it.
The problem isn’t directly in the specific vunerability but that you produce a crypto program and make false claims about it.
It’s a standard for people who produce good crypto to care about vunerabilities of their software and don’t overstate the capabilities of their software.
Your understand of trust is so poor that you said that PGP would have be known to be flawed for the possibility for information to be transmitted as Pentashagon and me claimed.
Most people who want to hide a picture on their phone likely don’t need real security anyway so it’s not bad if you make a few errors here and there.