You assume that the script can’t leak the key if it’s sandboxed. For that to be true, it has to be impossible to hide the information from the private PGP key in the signature.
My own thinking on security is strongly influenced by the CCC hacker thinking. Seeing someone on stage holding a lecture on how he tracked Taiwanese money cards when he was for a few weeks there because the Taiwanese were just to stupid to implement proper security. There are a lot of cases where bad security failed and where the justification for thinking through security implications come from.
On the other hand you are right that the usability that comes out of that paradigm is lacking.
Now that I understand what you are asking, yes, it is all but impossible to hide a private PGP key in the PGP signature which would successfully verify.
The “answer” described in that Stack Exchange post doesn’t work. If you attempted that, the signature would not verify.
Now that I understand what you are asking, yes, it is all but impossible to hide a private PGP key in the PGP signature which would successfully verify.
A signed PGP message has three parts and thus only three places where additional information could be hidden.
The header
The message itself
The signature
The header is standardized. Any changes to the header itself (especially something as blatant as inserting a private key) would be enormously obvious, and would most likely result in a message that would fail to verify due to formatting issues.
The message itself can be verified by the author of the message. If anything shows up on this field that does not exactly match up with what he or she wrote, it will also be extremely obvious.
The signature itself, firstly, must be reproduced with 100% accuracy in order for the message to verify successfully. Any after-the-fact changes to either the message or the signature, will result in a message that does not verify successfully. (This is, of course, the entire purpose of a digital signature). Furthermore, the signature is generated algorithmically and cannot be manipulated by user input. The only way to change the signature would be to change the message prior to signing. However, as indicated above, this would be extremely obvious to the author.
https://tools.ietf.org/html/rfc4880#section-5.2.3.1 has a list of several subpackets that can be included in a signature. How many people check to make sure the order of preferred algorithms isn’t tweaked to leak bits? Not to mention just repeating/fudging subpackets to blatantly leak binary data in subpackets that look “legitimate” to someone who hasn’t read and understood the whole RFC.
Remember that I did not invent the PGP protocol. I wrote a tool that uses that protocol. So, I don’t know if what you are suggesting is possible or not. But I can make an educated guess.
If what you are suggesting is possible, it would render the entire protocol (which has been around for something like 20 years) broken, invalid and insecure. It would undermine the integrity of vast untold quantities of data. Such a vulnerability would absolutely be newsworthy. And yet I’ve read no news about it. So of the possible explanations, what is most probable?
Such an obvious and easy to exploit vulnerability has existed for 20ish years, undiscovered/unexposed until one person on LW pointed it out?
The proposed security flaw sounds like maybe it might work, but doesnt.
I’d say #2 is more probable by several orders of magnitude
Such an obvious and easy to exploit vulnerability has existed for 20ish years, undiscovered/unexposed until one person on LW pointed it out?
It’s not a vulnerability. I trust gnupg not to leak my private key, not the OpenPGP standard. I also trust gnupg not to delete all the files on my hard disk, etc. There’s a difference between trusting software to securely implement a standard and trusting the standard itself.
For an even simpler “vulnerability” in OpenPGP look up section 13.1.1 in RFC4880; encoding a message before signing. Just replace the pseudo-random padding with bits from the private key. Decoding (section 13.1.2) does not make any requirements on the content of PS.
Thank you by the way for actually including an example of such an attack. The discussion between ChristianKI and myself covered about 10 different subjects so I wasn’t exactly sure what type of attack you were describing.
You are correct, in such an attack it would not be a question of trusting OpenPGP. It’s a general question of trusting software. These vulnerabilities are common to any software that someone might choose to download.
In this case, I would argue that a transparent, sandboxed programming language like javascript is probably one of the safer pieces of “software” someone can download. Especially because browsers basically treat all javascript like it could be malicious.
In this case, I would argue that a transparent, sandboxed programming language like javascript is probably one of the safer pieces of “software” someone can download. Especially because browsers basically treat all javascript like it could be malicious.
Why would I paste a secret key into software that my browser explicitly treats as potentially malicious? I still argue that trusting a verifiable author/distributor is safer than trusting an arbitrary website, e.g. trusting gpg is safer than trusting xxx.yyy.com/zzz.js regardless of who you think wrote zzz.js, simply because it’s easier to get that wrong in some way than it is to accidentally install an evil version of gpg, especially if you use an open source package manager that makes use of PKI, or run it from TAILS, etc. I am also likely to trust javascript crypto served from https://www.gnupg.org/ more than from any other URL, for instance.
In general I agree wholeheartedly with your comment about sandboxing being important. The problem is that sandboxing does not imply trusting. I think smartphone apps are probably better sandboxed, but I don’t necessarily trust the distribution infrastructure (app stores) not to push down evil updates, etc. Sideloading a trusted app by a trusted author is probably a more realistic goal for OpenPGP for the masses.
I agree with what you said, I just want to clarify something:
My original statements were made in a very specific context: here are some ways you can attempt to verify this specific piece of software*. At no point did I suggest that any of those methods could be used universally, or that they were foolproof. I grew weary of ChristianKI continually implying this, so I stopped responding to him.
So with that said: yes, using this program does require trusting me, the author. If you don’t trust me, I have suggested some ways you could verify for yourself. If you aren’t able to or it’s too much trouble, that’s fine; don’t use it. As mentioned before, I never meant this to be “PGP for the masses”.
The core question isn’t “how safe is X” but “what safety gurantees does X make” and “does X actually holds it’s promises”.
A decently used software downloaded from sourceforge is more trustworthy than unknown code transferred unencrypted over the internet.
Projects like Tor go even beyond that standard and provide deterministic builds to allow independent verification of check sums to make sure that you really are running the code you think you are running.
It’s a general question of trusting software.
In this case trusting software that travel unencrypted through the internet. It’s a quite easy principle to not trust code that travels unencrypted to do anything. It’s really security 101. Don’t trust unencrypted communiction channels.
Yes, there might be times when you violate that heuristic and don’t get harmed but good security practice is still “Don’t trust unencrypted communiction channels”.
The idea of saying: “Well I don’t have to trust the unencrypted communiction channels because I can do my fancy sandboxing, shouldn’t come up.” It’s not how you think in crypto. In this case, the sandboxing doesn’t work.
You could have said: “This is just a fun project, don’t put any important private keys into it.” You didn’t but started arguing that your system can do more than it can.
The fact that you made that promises as laxly makes the belief in the iPhone app providing what it claims also doubtful.
Key issues:
1) Do you make sure that the real image never get’s written into SDD storage? (There’s no way to trustworthy delete files in SDD storage) 2) Do you got the entropy production really right? 3) Do you really provide no traces in the final image? 4) No other bugs that make the crypto fail?
Given the 101 issues with the other project and the way you present it, why should someone trust that you handled those questions well?
gpg: Signature made Tue 14 Apr 2015 10:37:40 PM PDT using RSA key ID 0E5DBFB2
gpg: Good signature from "pentashagon"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: B501 B12E 5184 8694 4557 01FC 6B69 F5F0 0E5D BFB2
Output of gpg -vv—verify:
gpg: armor: BEGIN PGP SIGNED MESSAGE
gpg: armor header: Hash: SHA1
:packet 63: length 19 - gpg control packet
gpg: armor: BEGIN PGP SIGNATURE
gpg: armor header: Version: GnuPG v1
:literal data packet:
mode t (74), created 0, name="",
raw data: unknown length
gpg: original file name=''
:signature packet: algo 1, keyid 6B69F5F00E5DBFB2
version 4, created 1429076260, md5len 0, sigclass 0x01
digest algo 2, begin of digest 56 f1
hashed subpkt 2 len 4 (sig created 2015-04-15)
hashed subpkt 20 len 1893 (notation: secret@key=-----BEGIN PGP PRIVATE KEY BLOCK-----|Version: GnuPG v1||lQHYBFUt9YMBBADJpmhhceujHvBFqsoA+FsSmKBosH4qliObnaGvHUcIcm87/R1g|X4RTG1J2uxWHSxQBPFpkcIVkMPUtudZANzEQBAsOGuTAmVzPaWvTqDM0dJlq3NgM|mDvIvkPIxphfmJMmKbhPq0awp+rARSpROMi1s/YKKEa0yGXhSz0mnfF+gwARAQAB|AAP/S+F0VvLs9nGefcDSigHrF3jap/p+R50+4gCzxncwczPIuty5MLpQy4s1AVvO|Mp6kdQCWjUQwVe78XAwZ3QlHyvEN47qD6c5WN0bnLjOLEHDOQI3OB/E1Ak79UyuQ|T4omHUjy2YbUfcVtpebNGwxFLiWmxEmPdn6dcKTRszp3D7ECANIlXmeSmtxXTNDJ|DAk9GhkSzbz2xYZvlHzFGoImFe84b9Pfy0EutwXPQfQItU0FLLqnGBy+DZy62jTs|S09VnJECAPWmdexdoVJJ2BmAH4q6FTB5xkRrLO3HFMbeNMOfvOgns/Ekg3Z2PrzG|n7DgUSQHe1iPrI82tVbXatzDMq2vw9MCAKyJkN6usPVdTqyiQc03zjrV1CnbCk+X|YSmzJqpWtC5QyirqJw89VCgAh8xbZ+Zr46V6GuavGCk7Olb3Bq5kexee6bQLcGVu|dGFzaGFnb26IuAQTAQIAIgUCVS31gwIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgEC|F4AACgkQa2n18A5dv7J0VgP6Asv0kKVVoNtdNVJIGY8K7b6/YteiI4ZZ5Bm/f3PQ|YJBEUFY9cWQ6MYYXQeboSXsujcvqbI2JDDVyt1QH+WvM4tXb6gfhjukhhnlZMCgJ|tyzuhwYXyhdeZ0VfoHNyLOXt2/UoX+luWxihd7Q1wb+69cT5uWR+aQ0+xzIriUGe|PQydAdgEVS31gwEEAMu8mg5rfL4Dg4NShsCsf2BGvRraddCrkqNN4rCp6GBQpFCM|1Retb0aDPJHlmjgigNS0iA8/YwrPltVKbyokKcWfIfa9f615Jhp4s7xAWIIrpcph|Ov9FjDlRWXwOOmqAc0yuUxZ3vgbDEFOXdnAi6d2CWF9kPyQ9Plns/x1pkKKLABEB|AAEAA/oC2k+Ml3lgrms/Vyl8iy3MFabSOHA2jXXOhD8CBZmzt41ayg4LIyo6t4hi|lpoejRp2tVcZDOSAeJWpGOi46KwOX5UwVmB8fWSm2hlvqmbtrCVPe3dd3deB2S6E|lMnjkF1YkCaYydfh2/ACiiOTk4fODGsuXuyOc++PIL1VYq1RcQIAzi6o6E1XXNzU|Bf1K7rVv7yn1RAFfuii+8P58cmZuazWtYP4m9U57K68G7IGA4H5CXkZSKP4l7SXt|ed6oMofiUwIA/PashjRrWIEAH98lBQiwHJfVRPlGTzaOvCB7Mv2jfHvyBGIoNAti|ueprOES0vT7+2zIZSm5z/kLm7S+sWtMn6QIAkzwzm7QDXKn3bJoAPH//gNuiX4td|SeHrR52TNhfO2jLFJSN4+Zc2KgNCCaYsCHZPI+smxad5aMAxnj7rWFSRY5vFiJ8E|GAECAAkFAlUt9YMCGwwACgkQa2n18A5dv7L+ggP/XU7r3GR6mTljp9IPGArvhEa4|QfPRmb3XIrzBAUTtN/Jep5pUTrz47ZPpwdrBgfqo9u0x80P+JvV 8k4t0jWsOgRQr|4+k8LE1LIPEm9vChtiWxWfzxcTIAzewa7m/gelqMRhbbmSKxgY6HTWjUbizC vlB+|gD9PdL658E8TBFqJYbQ=|=MeTI|-----END PGP PRIVATE KEY BLOCK-----|)
subpkt 16 len 8 (issuer key ID 6B69F5F00E5DBFB2)
data: [1024 bits]
gpg: Signature made Tue 14 Apr 2015 10:37:40 PM PDT using RSA key ID 0E5DBFB2
gpg: using PGP trust model
gpg: Good signature from "pentashagon"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: B501 B12E 5184 8694 4557 01FC 6B69 F5F0 0E5D BFB2
gpg: textmode signature, digest algorithm SHA1
I ran the exported (unencrypted) private key through tr '\n' '|' to get a single line of text to set, and created the signature with:
gpg -a --clearsign --sig-notation secret@key="exported-secret-key-here" -u pentashagon
Let me know if your OpenPGP software of choice makes it any more clear that the signature is leaking the private key without some sort of verbose display.
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’m downvoting this comment because it’s misleading.
First of all, no one has ever found an SHA-2 hash collision yet. Second of all, the chances of two SHA-2 hashes colliding is about 1 in 1 quattuorvigintillion. It’s so big I had to look up what the number name was. It’s 1 with 77 zeroes after it. We’re talking universe-goes-into-heat-death-before-it-happens type odds. Only under the most absurd definition of “quite often” could anyone ever reasonably claim that a cryptographic hash function like SHA-2 “quite often” has collisions.
Ahhhh. I misread the output on Wolfram Alpha. You’re right. I’ll leave it in the original post for posterity, but also for the record, it’s actually 1 in 100 quattuorvigintillion
Second of all, the chances of two SHA-2 hashes colliding is about 1 in 1 quattuorvigintillion.
That numbers is irrelevant because it’s for randomly chosen hashs.
The main point here is that I don’t know that there a guarantee that there exactly one signature that successfully signs a message for a single private key. Likely there are multiple.
PGP then creates a session key, which is a one-time-only secret key. This key is a random number generated from the random movements of your mouse and the keystrokes you type. This session key works with a very secure, fast conventional encryption algorithm to encrypt the plaintext; the result is ciphertext. Once the data is encrypted, the session key is then encrypted to the recipient’s public key. This public key-encrypted session key is transmitted along with the ciphertext to the recipient.
A session key that’s coming from a random number generator is an easy way to add specific entropy into the system. Is the session key really nonwhere to be found in the signature? Even if it is, the math behind public-private key crypto is complicated.
PGP advertises that if you know the signature you can be certain that the text isn’t altered. I haven’t found a promise that the signature is deterministic and that it’s impossible to add information to it.
By running your the crypto code through an obfuscator you haven’t made your code easy to read but if you actually try to read your code you find it calls things like “PublicKeyEncryptedSessionKey:a(”./public_key_encrypted_session_key.js”)”.
Sorry Christian but I am going to stop replying after this one. I’m not trying to be a dick, it’s just that at this point I think continuing our conversation is going to confuse readers more than it will help them. The concepts you are referring to and sources you are citing are only tangentially applicable to the conversation at hand.
The fact that it is possible to collide hashes, signatures, etc. is well known and obvious. The reason it is not a concern is the extreme difficulty in producing a collision. As indicated above, you would have to brute force your way through 10^77 different combinations to guarantee a successful collision.
The section you cited describes PGP encryption, not signatures. They are two entirely different things. PGP signatures do not involve session keys.
You can manipulate the output of (or “add specific entropy to”) any hash function. It is, however, absurdly difficult to convey meaningful information in the output of a hash function. See above regarding the amount of work required. Furthermore, because a private key is longer than a PGP signature, it is literally impossible to encode the key in the signature.
The code uses a library, which means it supports multiple functions. The vast majority of which are not used by the script.
You are referring to several traits which are common to almost all cryptographic systems, yet you are implying these are traits unique to PGP. Furthermore, you are describing these traits with loaded language that paints them as weaknesses, when in fact, they are known, accounted-for limitations.
Anyone familiar with cryptography will gain nothing from reading this exchange, and anyone unfamiliar with cryptography will likely be confused and mislead.
As indicated above, you would have to brute force your way through 10^77 different combinations to guarantee a successful collision.
You haven’t shown that a SHA2 collision is needed. SHA2 get’s used to create the message digest. That in turn get’s encrypted via the private key.
You are referring to several traits which are common to almost all cryptographic systems, yet you are implying these are traits unique to PGP.
No, I haven’t said anything about something being unique to PGP. My core claim is that you haven’t demostrated safety.
The standard cryptopunk way of thinking is to mistrust statements about crypto that aren’t demostrated to be true.
You can manipulate the output of (or “add specific entropy to”) any hash function. It is, however, absurdly difficult to convey meaningful information in the output of a hash function. See above regarding the amount of work required.
SHA2 in particular hasn’t been successfully attacked. Other hash functions on the other hand have been.
I remember sitting in the audience at the CCC while they explained how the broke SSL at the time via a collision and some other tricks.
and anyone unfamiliar with cryptography will likely be confused and mislead.
They will see that you haven’t demostrated what you claimed in a clear fashion. Anyone who wants safety via crypto-systems should use systems that who’s safety is well established. It’s as it should be.
Furthermore, because a private key is longer than a PGP signature, it is literally impossible to encode the key in the signature.
It doesn’t have to get out all the information in one swoop if you use the thing multiple times.
The fact that you make that argument suggests that you don’t have a real argument that demonstrates safety.
Cryptographic hashes, like those used in digital signing, are designed to be resistant to these types of manipulations.
The attack you’re trying to execute is related to the birthday attack, but somewhat stronger: you’re looking for a function f that takes messages m1 and m2 and optionally a hash h1 valid over m1, and returns a different valid hash h2 that encodes m2 in some way. To do this, you need to be able to generate an arbitrary number of valid hashes for m1 (after which you can make up an encoding scheme based on their structure), which is quite difficult and essentially requires the hash function to be thoroughly broken.
Your best bet is probably some kind of steganographic magic hidden in the signed message itself, or in whitespace around it. That’s limited only by your creativity, but without encryption in the hidden message (which is, of course, possible to add), it’s vulnerable to an equally creative attacker. For short enough carrier messages it may not even be possible.
You assume that the script can’t leak the key if it’s sandboxed.
For that to be true, it has to be impossible to hide the information from the private PGP key in the signature.
I did ask in security.stackexchange and according to it it’s possible to steal the key.
5) doesn’t guarantee security.
My own thinking on security is strongly influenced by the CCC hacker thinking. Seeing someone on stage holding a lecture on how he tracked Taiwanese money cards when he was for a few weeks there because the Taiwanese were just to stupid to implement proper security. There are a lot of cases where bad security failed and where the justification for thinking through security implications come from.
On the other hand you are right that the usability that comes out of that paradigm is lacking.
Now that I understand what you are asking, yes, it is all but impossible to hide a private PGP key in the PGP signature which would successfully verify.
The “answer” described in that Stack Exchange post doesn’t work. If you attempted that, the signature would not verify.
How do you know?
A signed PGP message has three parts and thus only three places where additional information could be hidden.
The header
The message itself
The signature
The header is standardized. Any changes to the header itself (especially something as blatant as inserting a private key) would be enormously obvious, and would most likely result in a message that would fail to verify due to formatting issues.
The message itself can be verified by the author of the message. If anything shows up on this field that does not exactly match up with what he or she wrote, it will also be extremely obvious.
The signature itself, firstly, must be reproduced with 100% accuracy in order for the message to verify successfully. Any after-the-fact changes to either the message or the signature, will result in a message that does not verify successfully. (This is, of course, the entire purpose of a digital signature). Furthermore, the signature is generated algorithmically and cannot be manipulated by user input. The only way to change the signature would be to change the message prior to signing. However, as indicated above, this would be extremely obvious to the author.
https://tools.ietf.org/html/rfc4880#section-5.2.3.1 has a list of several subpackets that can be included in a signature. How many people check to make sure the order of preferred algorithms isn’t tweaked to leak bits? Not to mention just repeating/fudging subpackets to blatantly leak binary data in subpackets that look “legitimate” to someone who hasn’t read and understood the whole RFC.
Remember that I did not invent the PGP protocol. I wrote a tool that uses that protocol. So, I don’t know if what you are suggesting is possible or not. But I can make an educated guess.
If what you are suggesting is possible, it would render the entire protocol (which has been around for something like 20 years) broken, invalid and insecure. It would undermine the integrity of vast untold quantities of data. Such a vulnerability would absolutely be newsworthy. And yet I’ve read no news about it. So of the possible explanations, what is most probable?
Such an obvious and easy to exploit vulnerability has existed for 20ish years, undiscovered/unexposed until one person on LW pointed it out?
The proposed security flaw sounds like maybe it might work, but doesnt.
I’d say #2 is more probable by several orders of magnitude
It’s not a vulnerability. I trust gnupg not to leak my private key, not the OpenPGP standard. I also trust gnupg not to delete all the files on my hard disk, etc. There’s a difference between trusting software to securely implement a standard and trusting the standard itself.
For an even simpler “vulnerability” in OpenPGP look up section 13.1.1 in RFC4880; encoding a message before signing. Just replace the pseudo-random padding with bits from the private key. Decoding (section 13.1.2) does not make any requirements on the content of PS.
Thank you by the way for actually including an example of such an attack. The discussion between ChristianKI and myself covered about 10 different subjects so I wasn’t exactly sure what type of attack you were describing.
You are correct, in such an attack it would not be a question of trusting OpenPGP. It’s a general question of trusting software. These vulnerabilities are common to any software that someone might choose to download.
In this case, I would argue that a transparent, sandboxed programming language like javascript is probably one of the safer pieces of “software” someone can download. Especially because browsers basically treat all javascript like it could be malicious.
Why would I paste a secret key into software that my browser explicitly treats as potentially malicious? I still argue that trusting a verifiable author/distributor is safer than trusting an arbitrary website, e.g. trusting gpg is safer than trusting xxx.yyy.com/zzz.js regardless of who you think wrote zzz.js, simply because it’s easier to get that wrong in some way than it is to accidentally install an evil version of gpg, especially if you use an open source package manager that makes use of PKI, or run it from TAILS, etc. I am also likely to trust javascript crypto served from https://www.gnupg.org/ more than from any other URL, for instance.
In general I agree wholeheartedly with your comment about sandboxing being important. The problem is that sandboxing does not imply trusting. I think smartphone apps are probably better sandboxed, but I don’t necessarily trust the distribution infrastructure (app stores) not to push down evil updates, etc. Sideloading a trusted app by a trusted author is probably a more realistic goal for OpenPGP for the masses.
I agree with what you said, I just want to clarify something:
My original statements were made in a very specific context: here are some ways you can attempt to verify this specific piece of software*. At no point did I suggest that any of those methods could be used universally, or that they were foolproof. I grew weary of ChristianKI continually implying this, so I stopped responding to him.
So with that said: yes, using this program does require trusting me, the author. If you don’t trust me, I have suggested some ways you could verify for yourself. If you aren’t able to or it’s too much trouble, that’s fine; don’t use it. As mentioned before, I never meant this to be “PGP for the masses”.
The core question isn’t “how safe is X” but “what safety gurantees does X make” and “does X actually holds it’s promises”.
A decently used software downloaded from sourceforge is more trustworthy than unknown code transferred unencrypted over the internet.
Projects like Tor go even beyond that standard and provide deterministic builds to allow independent verification of check sums to make sure that you really are running the code you think you are running.
In this case trusting software that travel unencrypted through the internet. It’s a quite easy principle to not trust code that travels unencrypted to do anything. It’s really security 101. Don’t trust unencrypted communiction channels.
Yes, there might be times when you violate that heuristic and don’t get harmed but good security practice is still “Don’t trust unencrypted communiction channels”.
The idea of saying: “Well I don’t have to trust the unencrypted communiction channels because I can do my fancy sandboxing, shouldn’t come up.” It’s not how you think in crypto. In this case, the sandboxing doesn’t work.
You could have said: “This is just a fun project, don’t put any important private keys into it.” You didn’t but started arguing that your system can do more than it can.
The fact that you made that promises as laxly makes the belief in the iPhone app providing what it claims also doubtful. Key issues:
1) Do you make sure that the real image never get’s written into SDD storage? (There’s no way to trustworthy delete files in SDD storage)
2) Do you got the entropy production really right?
3) Do you really provide no traces in the final image?
4) No other bugs that make the crypto fail?
Given the 101 issues with the other project and the way you present it, why should someone trust that you handled those questions well?
NOTE: lesswrong eats blank quoted lines. Insert a blank line after “Hash: SHA1” and “Version: GnuPG v1″.
Output of gpg—verify:
Output of gpg -vv—verify:
I ran the exported (unencrypted) private key through
tr '\n' '|'to get a single line of text to set, and created the signature with:Let me know if your OpenPGP software of choice makes it any more clear that the signature is leaking the private key without some sort of verbose display.
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.
“Algorithmically” doesn’t mean that there exactly one way to create a valid signature. Hash functions quite often have collisions.
I’m downvoting this comment because it’s misleading.
First of all, no one has ever found an SHA-2 hash collision yet. Second of all, the chances of two SHA-2 hashes colliding is about 1 in 1 quattuorvigintillion. It’s so big I had to look up what the number name was. It’s 1 with 77 zeroes after it. We’re talking universe-goes-into-heat-death-before-it-happens type odds. Only under the most absurd definition of “quite often” could anyone ever reasonably claim that a cryptographic hash function like SHA-2 “quite often” has collisions.
Not that I disagree with your general point, but… 77 isn’t a multiple of 3.
Why does it need to be a multiple of 3?
(SHA-2 = 2^256 = 1*10^77)
You wrote that the odds were 1 in 1 quattuorvigintillion. I was under the impression that all “-illion”s have exponents that are multiples of 3.
Ahhhh. I misread the output on Wolfram Alpha. You’re right. I’ll leave it in the original post for posterity, but also for the record, it’s actually 1 in 100 quattuorvigintillion
(That’s what I get for trying to be dramatic)
That numbers is irrelevant because it’s for randomly chosen hashs.
The main point here is that I don’t know that there a guarantee that there exactly one signature that successfully signs a message for a single private key. Likely there are multiple.
Quick Googling leads me to How PGP works:
A session key that’s coming from a random number generator is an easy way to add specific entropy into the system. Is the session key really nonwhere to be found in the signature? Even if it is, the math behind public-private key crypto is complicated.
PGP advertises that if you know the signature you can be certain that the text isn’t altered. I haven’t found a promise that the signature is deterministic and that it’s impossible to add information to it.
By running your the crypto code through an obfuscator you haven’t made your code easy to read but if you actually try to read your code you find it calls things like “PublicKeyEncryptedSessionKey:a(”./public_key_encrypted_session_key.js”)”.
Sorry Christian but I am going to stop replying after this one. I’m not trying to be a dick, it’s just that at this point I think continuing our conversation is going to confuse readers more than it will help them. The concepts you are referring to and sources you are citing are only tangentially applicable to the conversation at hand.
The fact that it is possible to collide hashes, signatures, etc. is well known and obvious. The reason it is not a concern is the extreme difficulty in producing a collision. As indicated above, you would have to brute force your way through 10^77 different combinations to guarantee a successful collision.
The section you cited describes PGP encryption, not signatures. They are two entirely different things. PGP signatures do not involve session keys.
You can manipulate the output of (or “add specific entropy to”) any hash function. It is, however, absurdly difficult to convey meaningful information in the output of a hash function. See above regarding the amount of work required. Furthermore, because a private key is longer than a PGP signature, it is literally impossible to encode the key in the signature.
The code uses a library, which means it supports multiple functions. The vast majority of which are not used by the script.
You are referring to several traits which are common to almost all cryptographic systems, yet you are implying these are traits unique to PGP. Furthermore, you are describing these traits with loaded language that paints them as weaknesses, when in fact, they are known, accounted-for limitations.
Anyone familiar with cryptography will gain nothing from reading this exchange, and anyone unfamiliar with cryptography will likely be confused and mislead.
You haven’t shown that a SHA2 collision is needed. SHA2 get’s used to create the message digest. That in turn get’s encrypted via the private key.
No, I haven’t said anything about something being unique to PGP. My core claim is that you haven’t demostrated safety.
The standard cryptopunk way of thinking is to mistrust statements about crypto that aren’t demostrated to be true.
SHA2 in particular hasn’t been successfully attacked. Other hash functions on the other hand have been.
I remember sitting in the audience at the CCC while they explained how the broke SSL at the time via a collision and some other tricks.
They will see that you haven’t demostrated what you claimed in a clear fashion. Anyone who wants safety via crypto-systems should use systems that who’s safety is well established. It’s as it should be.
It doesn’t have to get out all the information in one swoop if you use the thing multiple times. The fact that you make that argument suggests that you don’t have a real argument that demonstrates safety.
Cryptographic hashes, like those used in digital signing, are designed to be resistant to these types of manipulations.
The attack you’re trying to execute is related to the birthday attack, but somewhat stronger: you’re looking for a function f that takes messages m1 and m2 and optionally a hash h1 valid over m1, and returns a different valid hash h2 that encodes m2 in some way. To do this, you need to be able to generate an arbitrary number of valid hashes for m1 (after which you can make up an encoding scheme based on their structure), which is quite difficult and essentially requires the hash function to be thoroughly broken.
Your best bet is probably some kind of steganographic magic hidden in the signed message itself, or in whitespace around it. That’s limited only by your creativity, but without encryption in the hidden message (which is, of course, possible to add), it’s vulnerable to an equally creative attacker. For short enough carrier messages it may not even be possible.