BitCoin BubbleFollow

Incorrect

To show you can and get a job plugging that hole.

Wrong.

Uh... Smash is technically correct, and Yoda's whole "brute force" statement is absolutely wrong, but the result isn't really what Smash is implying either. Yes. Single pad encryption can't be broken. But there are several conditions, and the first of them is a biggie. It's only perfectly secure *if* the key is the same length as what you're encrypting. If it's not, there's a possibility of detecting a repeating pattern. This is problematic if we're dealing with anything other than short text messages since there's no way someone's going to just remember a 50,000 character password. Ergo, the key has to be stored somewhere, almost certainly digitally given the data type we're talking about, which means if you can get to the data in the first place, you can probably get to the key. It's not like there's any value in this scenario to be transmitting the encrypted bitcoins around or anything. You're just storing it somewhere. So there's no real difference between storing it unencrypted on some removable device you have hidden in your mattress and storing it on your computer, and hiding the key on a removable device you have hidden in your mattress. You're fooling yourself if you think it's more secure.



Problem is that the use model we're talking about doesn't lend itself to single pad being used properly. I'll point out again that all the side methods you'd use to secure the key could also be used just as effectively to secure an unencrypted file. You gain very close to zero extra security doing this. Single pad encryption is most effective when pointA and pointB have obtained the only two copies of a key previously (and hopefully securely). PointA encrypts using the key and then destroys their copy. The encrypted message is then sent via a presumably insecure method to pointB, where it's decrypted using their copy of the key (which is then destroyed as well).

There is no value to encrypting something at pointA, and then holding onto the key in order to decrypt it at pointA at some point in the future. As I said, you gain zero security doing that because you've kept the key you used to encrypt it. Also, it only makes sense to use this method if you have a secure way of distributing keys, but it's time consuming or cumbersome, and you need a means to communicate quickly and securely via otherwise insecure means. If you had plenty of time to transmit the message, you'd just send it the same way you send the keys, right? So once again, the use model fails.



It's not that simple either, and once again, the means typically used to "hack" encryption really only means longer time, not increased difficulty. It's not useless of course, but it's also incredibly dependent on *what* is being encrypted.


Edited, Apr 4th 2013 2:10pm by gbaji

I think your idea of "small" in this case isn't going to work. How many bytes? Every character of data would need to match a character in the key for this to work as a perfect single pad encryption. So depending on character set, block sizes, whatever, a 1k file might require a 1,000 character key. A 1MB file would require a 1 million character field (yeah, I'm rounding).

"Pretty Small" in modern computing terms is still astronomically large in terms of human accessible strings of data.



Yes. Obviously. My point is that if this wasn't the case (meaning you could securely send keys and could wait until the next time you did so to send the message), you wouldn't need to bother with sending the keys. You'd just send the data, right?



Correct. That's the entire point. Again, this assumes that there's some secure time/method at which you can share keys ahead of time, but you'll need to send messages via insecure means. If those conditions don't exist, then single pad encryption isn't terribly useful. Sure the encryption is secure, but you aren't actually buying yourself anything by using it. I could take my dinner out of the oven, lock it in a safe, the immediately unlock the safe and eat my dinner. Or I could just eat my dinner. The process of using the safe didn't make my dinner any more safe in that case. Neither does using single pad encryption in this case.

Na na na na na na na na Batcoin!

You didn't bother to read my whole post did you? Why not just store the unencrypted file on a physical device not connected to anything then? Do you see how this offers exactly the same level of protection?



That's ironic given you're making a classic computer security error right now.




Put a flash drive with the unencrypted file in a safe, done, secure forever unless someone can physically acquire the flash drive in which case they can likely shoot you in the face or the like, rendering the loss of your bit-coin fairly trivial.

Do you understand why one is identical to the other in terms of security?

The key can be stored in a separate location, so both need to be found instead of just one. If you're only going to bother hiding one, then you're right, there's no point. But then this is why it's preferable to not have the key anywhere but your memory.

Edited, Apr 4th 2013 9:27pm by Rachel9

Put a flash drive with the unencrypted file in a safe, done, secure forever unless someone can physically acquire the flash drive in which case they can likely shoot you in the face or the like, rendering the loss of your bit-coin fairly trivial.

Do you understand why one is identical to the other in terms of security?

Do I understand your argument, yes. Is it correct, no. If it were, multi-factor authentication wouldn't exist. Oddly, it does. Can you see why?

I store my key in the Transgender Rights thread. Good luck finding it.

Edited, Apr 5th 2013 1:55pm by Spoonless

Um... It's correct Smash. Set your ego aside for a second (if that's possible). If your security model absolutely depends on securing an unencrypted file from being accessed by someone else, then it does not matter if that unencrypted file is the wallet file or the file containing the key to decrypt that wallet file. Thinking otherwise shows how you really don't have a clue what the hell you're talking about.




I see that you've memorized a term that you don't understand and doesn't actually apply to this case. No one's arguing we can't apply additional layers of security. But those additional layers (which on their own may add some additional security) don't have any bearing on the basic question of whether the file we're keeping on a offline storage device contains the unencrypted data we're securing *or* the keys to decrypt the data. And frankly, one can argue strongly that it's safer to do the former rather than the latter, since the latter assumes you're keeping the encrypted file someplace where others may see it. Which means you've given information to a potential hacker that the former state doesn't (that you must have an decryption key somewhere and he should try to obtain it).


Seriously, there are like whole chapters in security books dedicated to trying to explain (often unsuccessfully unfortunately) to neophyte's why what you're trying to do is a mistake.

Edited, Apr 5th 2013 2:06pm by gbaji

Um... It's correct Smash

It's not. I'm not going to argue about it any longer, we'll agree to disagree. I can see why you don't understand, I can't think of an easy way for you to understand, I can't think of anything gained by doing so.