#### Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

•  Subject
• Author
• Posted on
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?

raydenxy@yahoo.com (07-07-12 16:13:58):

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.

--=20
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.

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.

--

John (john@os2.dhs.org)

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.

--=20
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
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:

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.

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.

raydenxy@yahoo.com (07-07-13 14:55:55):

No.  Knowing part of the plaintext makes it easier to find the entire
ciphertext.  It does not make it easier to find the key.

This really depends on what you want to do with it.  If you're
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.

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.

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.

--=20
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.

Typo, sorry.  Replace `ciphertext' by `plaintext'.

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?

raydenxy@yahoo.com (07-07-14 03:06:33):

Of course it's possible.  Just read the man-page or the FAQ.

Regards,
Ertugrul S=C3=B6ylemez.

--=20
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"?

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 please go back to the kindergarten?  At least stop posting
incompetent bullshit.

Regards,
Ertugrul S=C3=B6ylemez.

--=20
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.

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.

Correct.  Thanks for clarifying this.

Regards,
Ertugrul S=C3=B6ylemez.

--=20
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.

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.