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

**posted on**

- raydenxy

July 12, 2007, 11:13 pm

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?

## Re: question about gpg

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.

## Re: question about gpg

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)

## Re: question about gpg

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.

## Re: question about gpg

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.

## Re: question about gpg

On Fri, 13 Jul 2007 14:55:55 -0700, raydenxy@yahoo.com wrote:

If that were true, public-key cryptography would be weak,

because

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

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.

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 everyplace 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.

## Re: question about gpg

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

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.

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.

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

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.

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.

## Re: question about gpg

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?

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?

## Re: question about gpg

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.

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.

## Re: question about gpg

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.

## Re: question about gpg

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.

## Re: question about gpg

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.

#### Site Timeline

- » need help with testing hackinglinuxexposed.com article on ssh authorized_keys
- — Next thread in » Linux Security

- » IPsec tunnel using racoon
- — Previous thread in » Linux Security

- » Cloud Ace Technologies is offering Implementation Services on Cloud Computing, Cloud Serv...
- — Newest thread in » Linux Security

- » ssh on command line: force using a group size (prime size) of 1024 (and no...
- — The site's Newest Thread. Posted in » Secure Shell Forum