Silk Road forums
Discussion => Security => Topic started by: flashlight5 on July 10, 2013, 11:36 am
-
if someone, that I want to send a message to, is using a short Bit key, will the security increase (longer to decrypt), when writing a longer message?
-
Maybe a few milliseconds if you pad it enough. The key to decrypt is encrypted asymmetrically with RSA, after the RSA encryption is broken and they obtain the session key then they decrypt the symmetrically encrypted payload with it. So you are already fucked once they break RSA, but technically you could add a truly insignificant and in most cases not even perceptible amount of time to the decryption process by making the message longer.
-
I thought setting encryption to 4096 bit was the cat's ass in terms of security?
-
I thought setting encryption to 4096 bit was the cat's ass in terms of security?
takes much longer (very very very long) using brute force
-
Um... I'm not absolutely sure what the question is actually asking, but I believe kmfkewm covered it. Except nobody but crypto enthusiasts are gonna have a fucking clue what he just said (LOL, no offense bro, but you know it's true -- even I barely followed it and I studied the stuff once upon a time).
Take this with a grain of salt, I don't understand it quite as well as he does but what he means is this: there's two keys when you encrypt a message. The key you provide is used to encrypt a second key. It's that second key that can decrypt the actual message itself (shit, it isn't the other way around right? LOL!) If the key provided is weak and short, making the message longer won't help because all that does is add extra stuff that needs to be decrypted by the second key. Getting to the second key has nothing to do with the message length.
It won't help protect against the first key being cracked, and once that's cracked, it's a simple matter of just decrypting a few extra words or whatever. It offers no additional security is the take away here. A 4096 bit RSA key is considered very secure. 2048 is still secure but not really great I believe. Anything less and an adversary will be able to decrypt your message if they try hard enough and have the knowledge and resources. I'm pretty sure that's today's situation.
Does that answer you...? :)
-
I think what kmfkewm is talking about is more for like https:// communication with a key exchange rather than PGP.
The message length won't matter with PGP; it's all about whether the user can guess or obtain the private key (and password if pw protected). By brute force the more bits in the key the better. I thought I read 912 bit has been cracked in about 141 days using like 300 personal computers in parallel.
-
you got a source? that would be kinda alarming... it means that this key strength is toast, since LE or any moron with a credit card has access to much faster computers in office or in the cloud.
Don't think that this is true... IT might have been true in a specific case, but I dont think its true for all cases in which 50% of all possible variations have to be assumed to be tested.
-
That was a while back I read that, I don't remember exactly where, I think it might have been
(clearnet)
http://www.dailytech.com/Japanese+Researchers+Crack+Supposedly+HackProof+Cryptography/article24965.htm
I don't think this was specifically a PGP key but it says:
The latest victim in the march of progress is pairing-based cryptography, an approach that was thought to hold the key to super-secure future communications. Japanese electronics giant Fujitsu Ltd. (TYO:6702), Kyushu University, and Japan’s National Institute of Information and Communications Technology (NICT) cracked a 278-digit (923-bit) cryptogram, easily besting the previous world record of 204 digits (676 bits).
Researchers who worked with pair-based cryptography have in the past expressed confidence that 900+ bit cryptograms would take hundreds of thousands of years to crack. But Fujitsu, et al. achieved the feat in a mere 148.2 days -- less than half a year -- running on a 21-computer cluster with 252 cores.
-
I think what kmfkewm is talking about is more for like https:// communication with a key exchange rather than PGP.
pgp does the key exchange for you - a pgp message is encrypted with a symmetric key which in turn is encrypted with a public key
-
Aah so PGP always encrypts message with a symmetric key and then encrypts that key with the assymetric key(s)? I knew it did this in the case of multiple recipients, didn't realise it did it all the time. Of course it makes sense since a single recipient is just a special case of multiple recipients! Why would the creators have programmed it to have two different methods!
-
Of course it makes sense since a single recipient is just a special case of multiple recipients!
I like your mind... :)
Oh, but it's in a totally not creepy way. Really. No, I mean it. Hey, wait, why are you walking away...? I'm not kidding, it isn't creepy at all! Wait, come back...!! :P
-
I think what kmfkewm is talking about is more for like https:// communication with a key exchange rather than PGP.
The message length won't matter with PGP; it's all about whether the user can guess or obtain the private key (and password if pw protected). By brute force the more bits in the key the better. I thought I read 912 bit has been cracked in about 141 days using like 300 personal computers in parallel.
It doesn't really matter with PGP, that is what I was trying to say. It is a technicality. Technically, message length correlates with the time it takes to decrypt a message, I believe in every possible case but don't quote me on that. When a message is encrypted with PGP, what really happens is that first a random session key is generated. The plaintext message is then encrypted symmetrically with the session key. Then the random session key is what is encrypted with RSA, the session key will be either 128 bits or 256 bits depending on the symmetric algorithm used. The final ciphertext block contains the asymmetrically encrypted session key as well as the symmetrically encrypted message. After the session key is discovered, it is fed into a symmetric algorithm. The best example I can think of is counter mode AES which is a stream cipher, block ciphers work differently but I think the same thing will apply. With AES in counter mode, you feed the algorithm the session key and then it outputs a key stream. You obtain the plaintext message by XORing each byte of the ciphertext with the matching byte outputted from the AES algorithm that you fed the session key to. So a bigger message means that the AES function needs to generate more bytes, and more XOR operations need to take place, so technically it will take longer to decrypt a longer message, but it isn't significant.
-
Thanks for the detailed info +1, it is very helpful.