“Confirm” meaning an attacker cannot demonstrate with ~100% certainty that the image isn’t of the type that could normally be found on the camera roll.
Nanashi
Karma: 474
You’re mostly correct. The data is encrypted, and then broken into a base-4 string. The least significant base-4 bit is dropped from each pixel leaving 98.4% fidelity, which is higher fidelity than the compression that gets applied. Thus in terms of image quality, the picture is indistinguishable from any other compressed image.
The encoding is deliberately reversible and also open-sourced. However, you can apply the same algorithm to any image, whether it’s a decoy or not, and get a string of possibly-encrypted-data. The only confirmation that the data is meaningful would be a successful decryption which is only possible with the correct passphrase.
All that said, the fact that the picture is indistinguishable from other non-decoy images only adds a trivial amount of entropy to the encryption. An attacker who is determined to brute force their way into your pictures can simply attempt to crack every picture in your camera roll, decoy or no.
Yes. Without the password, even a skilled attacker cannot confirm the presence of any metadata.
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.
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)
Why does it need to be a multiple of 3?
(SHA-2 = 2^256 = 1*10^77)
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.
I probably could have clarified: “N” stands for the number of lives you estimate this procedure could save above and beyond the “default”. In other words, “Net future lives saved with body-transplant technology” minus “Net future lives saved without body-transplant technology”
An example would be, say that there are not any viable hosts for a cadaver’s organs, so normally they would just have to cremate him which is +0 lives. But in this situation, they could transplant a head onto the body, which is +1 lives. And say that scenario plays out 50,000 times over the next however many years. So N=50,000.
Of course N will be much lower for you personally if you find that example (and other similar ones) unrealistic.
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.
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.
I don’t really understand the question. Why would someone want to hide their private PGP key in their public PGP signature?
It wouldn’t be every time you run the script; you would just need to vet it the first time. I expect that anyone using this for serious security purposes would just save the script locally. The point of this is that it’s browser-based, not cloud-based. Saving an HTML + Javascript file with a (admittedly rudimentary) GUI is infinitely easier than downloading a command-line based program.
If there’s precedent for successfully reattaching a head to a body, then keeping your head on ice after death has a much higher probability of “working”.
I think what I could have been more clear about was the use case here: this tool in its current form is sort of “pre-Alpha”. Previously the script was just sitting locally on my computer and I thought it could be useful to others. If I ever try to deploy this on any sort of larger scale, absolutely it will be done on an SSL server. But for right now, it’s just being shared amongst a few friends and the LW community.
If it turns out that people are using the tool frequently, I’ll probably go ahead and pay to upgrade my hosting plan to SSL. But for something that’s a free tool not meant for wide distribution, which takes about 7 seconds to right click and hit “Save As”, I just didn’t see it as necessary just yet.
Re: ethics
If the procedure works, you can estimate that its future application can be used to save N lives. You can assign an X% probability to the procedure working. As long as N*X is > 8, it would be more unethical to carve up the body and parcel out the organs.
Yeah… Ummmm..… There’s a lot wrong with this.
If I had malicious intent, it would not matter if my site were SSL or not.
If my site were compromised somehow, it would not matter if my site were SSL or not.
Everything about the script happens client-side.
The code is written in Javascript, thus you can verify #3 by simply looking at the source code.
If you’re not a programmer and don’t understand the source code and are still suspicious, you can copy the source code to a local file, and run it on a computer that’s sandboxed from the rest of the Internet.
Don’t get me wrong. I appreciate the need for constant vigilance, but this type of knee-jerk reaction is what prevents the wider scale adoption of good crypto practices.
Edit- for posterity’s sake: I accidentally down voted your post when I meant to upvote it. I wasn’t just being snide when I said “I appreciate the need for constant vigilance”, and it definitely resulted in a good discussion. I updated my vote.
Incidentally I also use Decoy as one method of PGP public key verification. The “decoy” picture is a screenshot of my public key. The photo hidden behind the decoy is a picture of me, holding up my drivers license and an index card with my username. The picture itself should prove sufficient in 99% of cases but in extreme circumstances I can give out the passcode which provides an additional two layers of verification (the validity of the password itself, and the photographic identity verification)
Of course that could still be spoofed if someone managed to replace all instances of my verification image, and then made a fake drivers license with my name on it and took a picture of that. But if that ever did happen I actually have a final layer of protection which I won’t tell anyone about until I can figure out a way to re-tell it without rendering it worthless.
I think that, for a bunch of people, their way of coping with death is to “accept” it as part of the natural order of things. Every time you watched parent, friend, relative, spouse, loved one, etc. die, you tell yourself that it had to happen. That’s just the way things are.
Then something like this comes along. And it’s an ugly reminder of the true scope of the tragedy of death: all those friends and loved ones, they didn’t “just have to” die, and instead of just being a natural thing that just happens to people, their death could have been prevented but wasn’t. And I think for a lot of people, it’s much easier to just dismiss insert life extending technology here than it is to accept that possibility.
For grins:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Information security is a pretty big passion of mine; I don’t think someone needs to have “something to hide” in order to make use of digital signing, encryption, etc. Another passion of mine is making things easier for other people to do. I’ve written a couple of tools that I think can be useful for the LW crowd.
Online PGP Signature: This is an online javascript-based tool which allows you to sign messages using your PGP private key. I love the idea of PGP-signed messages (I remember someone under the pseudonym “Professor Quirrell” handing out PGP-verified Quirrell points a few years back). The problem is, I had yet to find an easy way to do this that didn’t involve downloading command-line based software. So I wrote this tool that uses open-sourced, javascript-based PGP libraries to let you easily sign messages in your browser.
The whole thing is client-side so your private key is never seen by me, but be smart about security. If you don’t trust me, that’s fine, just don’t use the tool. But also remember that you could have a virus, your computer could be monitored, someone could be watching over your shoulder, etc. so please be smart about your security. But hopefully this can be helpful.
Decoy: an iPhone App: I wrote this after “The Fappening”, where I was basically appalled at the terrible security practices that pretty much everyone uses when sending pictures back and forth. Decoy uses a combination of steganography and AES encryption to let you send images back and forth without having to sign up for an account or use some outside service that can be hacked or otherwise compromised.
You take the original picture, then you come up with a passphrase, then you take a “decoy” picture. The original picture is converted to base64 image data, which is then AES-encrypted using your passphrase. The resulting cipher text is then encoded into the pixels of the “decoy” picture, which is what gets saved on your phone and sent out. The “decoy” pictures are indistinguishable from any other picture on your or your recipients’ camera rolls, and unless you have the passphrase, then the original image is thoroughly inaccessible.
If your phone is lost, hacked, stolen, or (more benignly) someone happens to be looking through pictures on your phone, all anyone will see are the “decoy” pictures. Without the password, those pictures are worthless. Although the app is primarily branded for, ahem, “personal use”, there are plenty of other ways to use it. For example, my wife and I use it for things like sending pictures of sensitive physical documents like credit cards, birth certificates, social security cards, etc.
(full disclosure: although Decoy is free, it is ad-supported so I do financially benefit from people using the app. But on the bright side I’m an avowed rationalist and if I make a quajillion dollars with this app I will spend the vast majority of it on LW-friendly causes!) -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v1.0.1 Comment: http://openpgpjs.org
wsBcBAEBCAAQBQJVKahLCRBBM9OD/oMSegAAWY8H/1ffbDiZ2GsLlBdjCOk7 H6R5fhxq4szBSyByJdfj4p+iH1X4OCDlh5e7eF1gDFxm2p3IeoEBuJWv0Y8K 2/deTzKQ6ZpHF5L7fHKjneA1JXtsOEIcRX30UlPvPVxJ2xJZFTJumeF9G9tR jjrheAbV/IrmOB8tq8+OwF3I7csnD9GkFTZZnquzMpVpG0KKE15hh8QhrUIH Z1xgReB9NBdHHdsOx3CQmUkae3W+7YtlXVKuDD0uFOBtUkb17oTrH0nVy1tg o0ITrwm1LzRwZn4qiWrHwcJld43kU5WcifSj+/nlMMmMbATmhVoNOkWeIszy V4a+yYKSwSDxDRmlLyAFvmg= =QufC -----END PGP SIGNATURE-----
Your first paragraph nails it. Unless your phone is both jail broken and seriously compromised, there is no means of viewing the “original” version of either picture. Also re: the second paragraph. The app forces you to take a picture from your device to use as the “Decoy”, it will not allow you to use an off-device image. (You CAN use an off-device image as the hidden picture).
As for the statistical analysis, it’s mostly irrelevant. The encoding algorithm is both reversible and published. So you can extract “Decoy data” from ANY picture that you find, Decoy or no. The only thing that will confirm it one way or the other is a successful decryption. The best you could do is say, “Based on certain telltales, there’s a 10% chance this image is a Decoy” or whatever the odds may be.
Such an attack has little to no value. If you are an attacker with a specific target, isolating which pictures are decoys removes a trivial amount of entropy from the equation, especially compared to the work of trying to brute-force an AES-encrypted ciphertext.