I just thought since the public key is used for encryption ,and the private for decryption,and as far as i know knowing some part of the encrypted data makes it easier to crack ...Exposing the public key it's still dangerous because one attacker could encrypt something with the stolen public key and then trying to crack hist own text or data to find the private key...which should be easier because he has de unencrypted version of his data.Am i right? Or as wrong as i can get?
> i just thought since the public key is used for encryption ,and the > private for decryption,and as far as i know knowing some part of the > encrypted data makes it easier to crack ...Exposing the public key > it's still dangerous because one attacker could encrypt something with > the stolen public key and then trying to crack hist own text or data > to find the private key...which should be easier because he has de > unencrypted version of his data.Am i right? Or as wrong as i can get?
You are right. The lone fact that your public key is public makes an offline attack possible. Let's talk about the average run-time of such an attack. If you can delay the heat death of the universe for another billion of years, then you might be able to find the corresponding private key. You get the point.
Regards, Ertugrul S=C3=B6ylemez.
-- Security is the one concept, which makes things in your life stay as they are. Otto is a man, who is afraid of changes in his life; so naturally he does not employ security.
> i just thought since the public key is used for encryption ,and the > private for decryption,and as far as i know knowing some part of the > encrypted data makes it easier to crack ...Exposing the public key > it's still dangerous because one attacker could encrypt something with > the stolen public key and then trying to crack hist own text or data > to find the private key...which should be easier because he has de > unencrypted version of his data.Am i right? Or as wrong as i can get?
No. If you know some of the plain text it can possibly help a brute force decryption, but knowledge of the public key has no bearing on this. The public key/private key pair are only used to encrypt a randomly generated session key, which is then used to encrypt the plain text using symetric encryption.
In public key cryptography, the public key is mathematically derived from the private key but cannot be used to recreate the private key. As a simple example of how this can work, when you divide one number by another and get a remainder, knowledge of the remainder does not in any way help you determine which 2 numbers were involved in the original problem.
> In public key cryptography, the public key is mathematically derived > from the private key but cannot be used to recreate the private key. > [...]
The private key is derived from the public one, the parameters of the latter being mostly hard-coded and well known. It would be extremely stupid to do this the other way round.
Regards, Ertugrul S=C3=B6ylemez.
-- Security is the one concept, which makes things in your life stay as they are. Otto is a man, who is afraid of changes in his life; so naturally he does not employ security.
Maybe you guys are right but i think you some of you misinterpreted my question.Everywhere i look it says that knowing part of the original message can make it easy on finding the private key.But my ideea was that if the bad intended person has access to the public key he can encrypt a message just like the original one he wan'ts to get his hands on.And since he encrypted that file (the cracker) he knows exactly the content .... wouldn't that make it easier for bruteforcing for the private key? Only John Thompson up there i think got my ideea. I also have another question: What would you guys recommend on using for private means of encryption : The passphrase one (gpg -c) with a really good password or the public key method. I am thinking of this scenario , i have a file "myfile" and i do "gpg -c myfile " and then give it a pass like this "gj8857&_+sfH$#FF" . Would it be more secure to use the public method for "myfile" with a key of 2048 bits(or longer)? I am asking this since i hear people saying it's better to use the public method even for personal encryption,despite i find it a little more time consuming when using it for pesonal means(and rather insecure because of the need to keep the public and the private keys on some media).From reading the original howtos for gpg and browsing the web i found out that using a password for about 2**128 bits it would be as strong as an encryption on 2048 length public method.Is that right? I am also wondering how can i fed a password from a file to gpg for the "gpg -c myfile" and decrypting too. Thanks for helping.
On Fri, 13 Jul 2007 14:55:55 -0700, raydenxy@yahoo.com wrote:
> Maybe you guys are right but i think you some of you > misinterpreted my question.Everywhere i look it says that > knowing part of the original message can make it easy on > finding the private key.
If that were true, public-key cryptography would be weak, because *anybody* can generate plaintext-ciphertext pairs, because the encryption key is, after all, public.
It is true that if I know that a ciphertext represents either "Yes" or "No", encrypted without random padding under a given public key, then I can figure out the plaintext by encrypting "Yes" and "No" and comparing the ciphertext. To deal with this problem, before the encryption step the plaintext is typically "formatted" in a way that involves many random bytes. This operation is variously referred to as "formatting", "encoding", or "padding", and dates back at least as far as my 1993 version of the PKCS #1 standard.
> I also have another question: What would you guys recommend on using > for private means of encryption : The passphrase one (gpg -c) with a > really good password or the public key method. I am thinking of this > scenario , i have a file "myfile" and i do "gpg -c myfile " and then > give it a pass like this "gj8857&_+sfH$#FF" . Would it be more > secure to use the public method for "myfile" with a key of 2048 > bits(or longer)?
Both a well-generated symmetric key of 128 bits and a well-generated public key of 2048 bits are currently strong enough for all but government-taunting applications. The weakest link will be elsewhere, most likely in your key-handling practices. You should therefor ask yourself which kind of cipher will allow you to use the more secure key-handling practices. The most conspicuous consideration of this sort is that if you use a symmetric-key system, the secret key will have to be handled every time and every place something is encrypted *and* every time and every place something is decrypted, whereas if you use a public-key system, the crucial secret is present only during decryption.
-- To email me, substitute nowhere->spamcop, invalid->net.
> Maybe you guys are right but i think you some of you misinterpreted my > question.Everywhere i look it says that knowing part of the original > message can make it easy on finding the private key.But my ideea was > that if the bad intended person has access to the public key he can > encrypt a message just like the original one he wan'ts to get his > hands on.And since he encrypted that file (the cracker) he knows > exactly the content .... wouldn't that make it easier for bruteforcing > for the private key? Only John Thompson up there i think got my ideea.
No. Knowing part of the plaintext makes it easier to find the entire ciphertext. It does not make it easier to find the key.
> I also have another question: What would you guys recommend on using > for private means of encryption : The passphrase one (gpg -c) with a > really good password or the public key method. I am thinking of this > scenario , i have a file "myfile" and i do "gpg -c myfile " and then > give it a pass like this "gj8857&_+sfH$#FF" . Would it be more > secure to use the public method for "myfile" with a key of 2048 > bits(or longer)?
This really depends on what you want to do with it. If you're encrypting your backup or your hard-disk, use symmetric ciphers, i.e. secret key ciphers. If you're encrypting email, use asymmetric ciphers, i.e. public key ciphers.
It's pretty easy to decide when it makes sense to use public key ciphers. For communication, use public key ciphers, for encrypting personal information, use secret key ciphers.
About the security: don't bother. They both are equivalently safe with current computing power. It's pretty much a usage scenario issue. If you passphrase is safe enough, you're all set. If you want to be even more safe, generate an encrypted random key file, save it somewhere. Then you need that file (which is itself protected by a passphrase) to decrypt.
This is safer in that someone, who doesn't have the key file, must search the entire key space to decrypt the ciphertext, or find weaknesses in the cipher itself. If the attacker does have access to the key-file, he still has to find out the passphrase used to encrypt it.
See the gpg documentation on how to do this.
> I am asking this since i hear people saying it's > better to use the public method even for personal encryption,despite i > find it a little more time consuming when using it for pesonal > means(and rather insecure because of the need to keep the public and > the private keys on some media).
Yes, you're right. It's completely pointless to use public key methods for private data, especially considering the fact that attack methods against asymmetric ciphers get faster all the time. That's why one or two decades ago, 768 bits asymmetric keys were considered secure, while today you need at least 2048 bits.
Further, as you probably noticed yourself, asymmetric ciphers are a lot slower.
> From reading the original howtos for gpg and browsing the web i found > out that using a password for about 2**128 bits it would be as strong > as an encryption on 2048 length public method.Is that right?
Yes. Roughly at least. Attacks (like all other algorithms) have a so-called asymptotic run-time, which is a rough estimate of the complexity of an attack regarding some parameter (like the number of key bits).
For the modern symmetric ciphers, the best attacks have an exponential run-time. That means, the time an attack needs roughly doubles with each key bit. This is not the case for asymmetric ciphers, where the best attacks have sub-exponential run-time. The time needed for an attack still grows fast with the number of bits, but not as fast as with symmetric ciphers.
By the way, there are asymmetric ciphers, for which the best known attack still has exponential run-time, but they are just too new to be useful, for now.
Regards, Ertugrul S=C3=B6ylemez.
-- Security is the one concept, which makes things in your life stay as they are. Otto is a man, who is afraid of changes in his life; so naturally he does not employ security.
Thank you guys! You kinda make some light here. But still nobody gave me the answer on how to feed gpg a passphrase from a file.Better from what you have said here I will reformulate my ideea so that it's more clear. Suppose I have a file,and i want to encrypt it using symmetric keys method.How do i call gpg to encrypt "myfile" with "mykey" using a symmetric algorithm.I only managed to give gpg a interactive passphrase(which could be also viewed as a key right?since it's of any length) like "gpg -c" but i want to make my passphrase(now a key) a bit longer like 128 bits(or more).Is it a way to do this in gpg ? Or should i use another tool?
> Thank you guys! You kinda make some light here. But still nobody gave > me the answer on how to feed gpg a passphrase from a file.Better from > what you have said here I will reformulate my ideea so that it's more > clear. Suppose I have a file,and i want to encrypt it using symmetric > keys method.How do i call gpg to encrypt "myfile" with "mykey" using a > symmetric algorithm.I only managed to give gpg a interactive > passphrase(which could be also viewed as a key right?since it's of any > length) like "gpg -c" but i want to make my passphrase(now a key) a > bit longer like 128 bits(or more).Is it a way to do this in gpg ? Or > should i use another tool?
Of course it's possible. Just read the man-page or the FAQ.
Regards, Ertugrul S=C3=B6ylemez.
-- Security is the one concept, which makes things in your life stay as they are. Otto is a man, who is afraid of changes in his life; so naturally he does not employ security.
On 13 Jul, 07:58, Ertugrul Soeylemez wrote: > John Thompson (07-07-12 22:19:48): > > In public key cryptography, the public key is mathematically derived > > from the private key but cannot be used to recreate the private key. > > [...] > The private key is derived from the public one, the parameters of the > latter being mostly hard-coded and well known. It would be extremely > stupid to do this the other way round. > Regards, > Ertugrul S=F6ylemez. > -- > Security is the one concept, which makes things in your life stay as > they are. Otto is a man, who is afraid of changes in his life; so > naturally he does not employ security.
What *are* you talking about? Can you even spell "one-way function"?
> > > In public key cryptography, the public key is mathematically > > > derived from the private key but cannot be used to recreate the > > > private key. > > > The private key is derived from the public one, the parameters of > > the latter being mostly hard-coded and well known. It would be > > extremely stupid to do this the other way round. > What *are* you talking about?
Now for the most stupid (i.e. you):
In RSA, you generate a secret (the prime factors), then you generate the public key (which is partially hard-coded in most implementations), and then you derive the secret key from it (since you know the prime factors).
> Can you even spell "one-way function"?
Can you please go back to the kindergarten? At least stop posting incompetent bullshit.
Regards, Ertugrul S=C3=B6ylemez.
-- Security is the one concept, which makes things in your life stay as they are. Otto is a man, who is afraid of changes in his life; so naturally he does not employ security.
On Sat, 28 Jul 2007 00:54:47 -0700, Nico wrote: > On 13 Jul, 07:58, Ertugrul Soeylemez wrote: >> John Thompson (07-07-12 22:19:48): >>> > In public key cryptography, the public key is mathematically derived >> > from the private key but cannot be used to recreate the private key. >> > [...] >>> The private key is derived from the public one, the parameters of the >> latter being mostly hard-coded and well known. It would be extremely >> stupid to do this the other way round. >>> Regards, >> Ertugrul Söylemez. >>> -- >> Security is the one concept, which makes things in your life stay as >> they are. Otto is a man, who is afraid of changes in his life; so >> naturally he does not employ security. > What *are* you talking about? Can you even spell "one-way function"?
Actually, I'm pretty sure he can; but I'm at a loss as to how either of you got sucked into this argument.
Security requires that knowledge of the public key be insufficient to derive the private key; i.e., that the private key not be derivable from the public key alone. There is no security requirement that the public key not be derivable from the private key alone. In practice, key generation can be any process that produces a public/private key pair, without either necessarily having been derived from the other. For example, you could generate an RSA key pair consisting of ( modulus, huge_public_exponent ) and ( modulus, private_exponent ), and *throw* *away* the factors of the modulus, so that neither key could be derived from the other.
I think ES is focussing on the fact that in the practical generation of an RSA key pair, you typically choose a convenient public exponent, then compute the corresponding private exponent -- using additional secret information, namely the factors of the modulus. I think omission of this last clause led to this misunderstanding.
-- To email me, substitute nowhere->spamcop, invalid->net.
> > > The private key is derived from the public one, the parameters of > > > the latter being mostly hard-coded and well known. It would be > > > extremely stupid to do this the other way round. > I think ES is focussing on the fact that in the practical generation > of an RSA key pair, you typically choose a convenient public exponent, > then compute the corresponding private exponent -- using additional > secret information, namely the factors of the modulus. I think > omission of this last clause led to this misunderstanding.
Correct. Thanks for clarifying this.
Regards, Ertugrul S=C3=B6ylemez.
-- Security is the one concept, which makes things in your life stay as they are. Otto is a man, who is afraid of changes in his life; so naturally he does not employ security.
On 29 Jul, 23:42, Ertugrul Soeylemez wrote: > Peter Pearson (07-07-28 17:50:43): > > > > The private key is derived from the public one, the parameters of > > > > the latter being mostly hard-coded and well known. It would be > > > > extremely stupid to do this the other way round. > > I think ES is focussing on the fact that in the practical generation > > of an RSA key pair, you typically choose a convenient public exponent, > > then compute the corresponding private exponent -- using additional > > secret information, namely the factors of the modulus. I think > > omission of this last clause led to this misunderstanding. > Correct. Thanks for clarifying this. > Regards, > Ertugrul S=F6ylemez.
OK, this makes more sense. I've been seeing some *amazingly* stupid claims on this and the comp.security.ssh from fools claiming that there's no point in encrypting passwords for file system storage, because you can generate the keys anyway from the encrypted storage so there's no point.
Similar reasoning is why Subversion stores its passwords in local clear-text, which still makes me twitch every time I think about.
Vulnerabilite.com ne peut être tenu responsable des propos tenus dans le Newsgroup comp.os.linux.security
Message de Ertugrul Soeylemez (do-not-spam-me@ertes.de) (13 Juillet 2007)
