Cryptography-Digest Digest #186, Volume #14 Thu, 19 Apr 01 19:13:01 EDT
Contents:
Re: "UNCOBER" = Universal Code Breaker (John Savard)
Re: Reusing A One Time Pad ("Paul Pires")
Re: OTP breaking strategy (newbie)
Re: Current best complexity for factoring? ("Tom St Denis")
Re: OTP breaking strategy ("Tom St Denis")
Re: OTP breaking strategy (SCOTT19U.ZIP_GUY)
Re: OTP breaking strategy (newbie)
Let's end this OTP argument ("Tom St Denis")
Re: OTP breaking strategy ("Joseph Ashwood")
Re: Thanks for all replies reg:passphrase salting ("Joseph Ashwood")
Rijndael/AES VB Code ("Phil Fresle")
Re: "UNCOBER" = Universal Code Breaker (newbie)
Re: "UNCOBER" = Universal Code Breaker ("Tom St Denis")
Re: OTP breaking strategy (newbie)
Re: Crypto question ("Robert M Best")
Re: OTP breaking strategy (newbie)
Re: Crypto question ("Shaft")
Re: Crypto question ("Ivo Brugman")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Thu, 19 Apr 2001 22:03:52 GMT
On Thu, 19 Apr 2001 14:38:17 -0300, newbie <[EMAIL PROTECTED]>
wrote, in part:
>If the message is 100101010
>and the ouput 1111111111
>you are quite sure to reject the "possible" key.
The fraction of possible keys that are statistically nonrandom is
nearly infinitesimal, and so this is unlikely to eliminate any
possible plaintexts. Furthermore, it is generally considered an error
when doing an OTP to reject random keys because they don't look
random, although using a pad consisting of 0000000...0000 to encrypt a
message would make all but the stoutest hearts quail. (We had an
interesting debate on this issue some time ago.)
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Thu, 19 Apr 2001 15:00:33 -0700
> And Freud was a mother fu*king as*hole that spawned a small universe of
> devils, like you perhaps. But that's as bit off topic so I will refrain
> from commenting any further. Perhaps in a psych group.
*PLONK*
I find your comments rude, agumentative, childish, biggoted
and irresponsible. Luckily, there is a way not to find you at
all any more.
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Thu, 19 Apr 2001 17:58:35 -0300
You are reaching what I had tried to prouve.
You could distinguish with extra-information which message is valid.
And select the message. Because, the plaintext is deterministic
sequence.
If you could distinguish truly random output and not random, you have
still a way to break it.
I know it is very hard. Very very hard. It is like rebuilding the
plaintext with very few information.
I said OTP could be broken practically.
In theory, I KNOW that is unbreakable, but If you combine the context
factor and other extra-information you can break it.
[EMAIL PROTECTED] wrote:
>
> newbie <[EMAIL PROTECTED]> wrote:
> : When you introduce the context factor all the messages are not
> : equiprobable.
> : That is the way to try to find out the input.
>
> : If I analyse any output of 128 bits I will obtain 2^128 messages. I know
> : that.
> : But all the messages are not 100% in the context.
> : And all the output are not 100% random.
> : I have two ways to select : context factor and degree of randomness.
>
> Okay, remember that you don't have access to the pad itself. Now, suppose I
> have two different pads and I encrypt the following two messages:
>
> SELL 750 SHARES
> BUY 1000 SHARES
>
> Since I am not reusing the OTP, I encode each message with a different
> pad. By some bizarre coincidence, the pads happen to encrypt their
> messages to exactly the same result: 5e8f128c65a30954371a7e494217ad
>
> Now, given that the two messages are reasonably within the same context here,
> how can you possibly tell which one I actually sent?
>
> You might be able to guess which one I sent by analyzing my business and maybe
> by planting spies in my office, but at that point, you haven't really broken
> the OTP. In fact, you might figure out that I need to send the "BUY 1000 SHARES"
> message, but because I made a mistake, I sent the "SELL 750 SHARES" message.
>
> --
> Mark Wutka
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Current best complexity for factoring?
Date: Thu, 19 Apr 2001 22:07:45 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Terry Boon) wrote in
> <[EMAIL PROTECTED]>:
>
> >
> >>Given this unless someone finds a factoring algorithm that is easier
> >>when the primes come after a long stream of composites, there is no
> >>additional risk.
> >
> >This is what I suspect. I would find it curious and surprising to
> >find a factoring algorithm that had this property.
> >
>
> You can bet the NSA has devoted a great deal of research into
> taking advantage of this flaw in the way primes are picked.
> But I don't think they would tell you how much of an advantage it
> is. Also many primes come in clumps. You could incrment by two then
> take the following prime if in a certain distance just to hopefully
> throw off such methods if they exist.
Are you a nutjob? You keep naming the NSA yet you ignore the fact that not
all posters (such as me) are not from the states. The NSA has no place in
Canada (assuming they know where Canada is....)
> >But for all the trouble that some people seem willing to go to to
> >generate random bits, it seemed a little strange to bias the
> >subsequent prime generation...
> >
>
> No more stranger than using a nonbijective compressor to compress
> in PGP before one encrypts. Also no stranger than doing a quick check
> using first few bytes of the encrypted file to see if one has the right
> key. All these things are weaknesses that the NSA is sure to exploit.
How? Prove it. You have to prove that you can't brute force a bijective
encoded message. So far your method may be "slower" but that's about it.
> If one is making ones own keys it it should allow for the testing
> of a new key instead of the Pus two method. It should also allow one
> to pick two prime via an extrenal program and them use them. But it
> doesn't the ease of use is what they push but it concentrates where
> an attacker can look for weaknesses.
You can make your own PGP keys. Just make a valid PGP key packet and import
it.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Thu, 19 Apr 2001 22:10:15 GMT
"newbie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> You are reaching what I had tried to prouve.
> You could distinguish with extra-information which message is valid.
> And select the message. Because, the plaintext is deterministic
> sequence.
> If you could distinguish truly random output and not random, you have
> still a way to break it.
> I know it is very hard. Very very hard. It is like rebuilding the
> plaintext with very few information.
> I said OTP could be broken practically.
> In theory, I KNOW that is unbreakable, but If you combine the context
> factor and other extra-information you can break it.
No you keep missing the important (I think you are ignoring my posts) facts.
An OTP is not breakable under ANY circumstances. You can get the info it's
hiding via other methods (i.e torture, just plain assuming the plaintext,
likely to be wrong) but you cannot break an OTP.
Just remember that there are lot of english sentences for a given n-char OTP
message, all of which are equal probable.
Just like (let's assume the message is zero padded or something)
I WALKED MY DOG TODAY 0
ME GOOD LIKE CAT 0
NOBODY READS MY POSTS 0
are all equal probable. There is no way to tell them from each other.
Tom
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: OTP breaking strategy
Date: 19 Apr 2001 22:05:23 GMT
[EMAIL PROTECTED] (newbie) wrote in <[EMAIL PROTECTED]>:
>So every bit-string is truly random.
>
>input : 10010101
>ciphertext 10100101
>output : 00110000
>
>this ouput is random?
if your source of randomness is a true rand gerator
then any output is possible. Including ouputs that
contain long string of zeroes or ones or even simily
asci text.
if you want 80 bits out ten byte worth of data
each of the possible 2**80 ouput strings has
1/2**80 probability of being picked
if the message out for the first 8 bytes was
"the dog " then there is a random string that could map it to
"asdfgghi"
however the message might have been
"go home " then there is a random string that could map it to
"asdfgghi"
each random string is as possible as the other. If you
used all of the possible "random string' the message could
have been any thing for the first 8 bytes and still
the cipher text could have been
"asdfgghi"
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Thu, 19 Apr 2001 18:06:12 -0300
You wrote :
> No that is a way to find that you know nothing about the inputs except the
> probabilities you knew before. I suggest you try my challenge, I think it
> would be enlightening for you.
I'm still waiting for decryption of my encrypted-message "crack it".
It was a single cipher. But not decrypted at date.
I can not challenge you, I'm nothing more than newbie that has a lot to
learn.
Amateur and newbie
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Let's end this OTP argument
Date: Thu, 19 Apr 2001 22:17:24 GMT
Below is a 8-bit per char (ASCII) encoded message using a winRNG as a OTP
pad (I don't know the pad even, well I know the message).
The message is null terminated so you are given one byte of the pad ...
69 d0 2c a8 d9 55 1a b8 79 41 0d af 4f 31 fe e1
b8 6e a2 2b f4 d4 64 cf be 9d b4 54 00 05 9c 3a
ba b4 e8 fd d2 f7 78 9f c6 c1 23 70 c0 7a c7 76
eb 00 90 05 68 12 b6 82 5e 2e 9e 16 3a ed 18 46
If you can tell me the message please disclose it here!
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Thu, 19 Apr 2001 15:13:55 -0700
"newbie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> So every bit-string is truly random.
>
> input : 10010101
> ciphertext 10100101
> output : 00110000
>
> this ouput is random?
It may be, depends on how you generated it.
>
> What is the probability that each of bit-string of size n to be truly
> random?
> I explain
> let the plain-text 0110101
> ciphertext OTP 1010010
> output 1101111
>
> is this output random?
It may be, depends on how you generated it.
> Let me choose all bit-string with only 1 or 2 0's as output
> They are corresponding certainly to some plaintext.
> Are they random?
It may be, depends on how you generated it.
>
> I'm not wrong. What I under-estimate is the probability that a defined
> bit-string could be truly random or not.
No you did not under-estimate, you ill-defined. Random does not mean that it
looks random, it means that by knowing all the information (generator, seed,
who kicked the box etc) you cannot on average compress the output. To give
you an example:
RC4
Key = $key
Inf_Stream = RC4($key)
That stream will almost certainly "appear" random. However by knowing the
value of $key, I can easily compress this value to an expression that says
RC4 keyed with $key. With a random string no compressor like that exists
> You can still know if the ouput is random or not.
No it has been proven that you cannot prove randomness based on the output,
you can only prove it based on the generator. Imagine for example a
generator that outputs only
(octal)657656763130135435406430216046053543543540365435431064 that stream
appears random (if it doesn't generate your own that appears random to you),
all copies of that generator produce only that number. That number is not
random, although it can be arbitrarily complex.
> When I introduce my selected word, even when I combine it with a true
> random string the ouput could be non random.
That depends on the combiner, using XOR that resulting string will be
random.
> Try to analyze all the ouput possible combined with truly random key,
> some output does not meet the need of randomness.
I'm sorry you are incorrect.
> Not 100%. Quite hundred per cent.
> That is my error.
> I recognize it.
I think your error is a misunderstanding of the word random. There is a
meaning in common English that is roughly equivalent to complex. In
mathematics it means that (assuming base 2) given all outputs before and
after the nth, it is impossible to guess the nth bit with a probability
higher than 0.5, for all n. It says nothing about whether the stream happens
to be all zero, that nth bit actually has a 0.5 probability of being 1 and
0.5 of being 0.
> suppose the random key as sample is 1001, my ciphertext is 1101
> I input all possibilities of input
> Input ciphertext output
>
> 0000 1101 1101
> 0001 1101 1100
> 0010 etc...
>
> Some inputs are selective. If the output does not meet conditions of
> randomness I eliminate it 111111111111111 or 111110111111 or
> 1110111111111011111 etc.... does not meet those conditions.
Then you are completely incorrect. You are mistaking complexity for
randomness, in mathematics they are seperate quantities. I'd suggest
stepping back, not worrying about whether it's 0 or 1, not worrying if there
appears to be patterns, and examining the entropy involved, because that is
the major issue. If the entropy of a location is the maximum that location
can hold (in the case of binary each location can hold 1 bit) then the pad
is perfect in that location, regardless of whether or not the pad is all 0s.
>
> I select by input and by output.
That is your very problem, _you_ are selecting. You need to control the
generator, make sure the generator does not malfunction. Whatever the
generator spits out use it regardless of what it spits out, it's not your
job to second guess the perfection.
> If the input is valid and the output is valid that is OK.
*All* possibilities are valid, so this statement is useless.
>
> But my question is : how many outputs I can eliminate?
To be perfectly precise, 0, you cannot eliminate a single output.
> I know with
> extra-informations witch input I can select.
No you know with extra input which appear more complex, but by eliminating
any patterns you see you are inducing patterns that you don't see, but an
experienced cryptanalyst will see them.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Thanks for all replies reg:passphrase salting
Date: Thu, 19 Apr 2001 14:55:39 -0700
It is becoming increasingly unlikely that the password/phrase will be
verified in that way. Kerberos has become the de facto standard, and the
existance of SRP, EKE, SPEKE, AEKE, etc is beginning to make an impact with
increasingly more programs supporting them. None of these would make it
possible to use a technique like what you gave. It's nothing against you,
it's just that somebody moved the target without telling you.
Now on to some things you got incorrect.
"Harald Korneliussen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> You see that though the demands on the defending
> computer increases, the demand on the attacking
> computer increases exponentially(?) more because the
> problem of finding the password AND the "salt" is much
> more difficult than taking the problems one after the
> other.
Actually the difference between the problems increases linearly with this
type of effort. This is because the salt will be randomly chosen, otherwise
it would be attackable and would not offer as much security. Because the
average value will be min+ (max-min)/2 the attacker only has to do 2x the
work of the defender (best case security wise), and this is a constant
value. So your gain is not exponential it is linear.
Joe
------------------------------
From: "Phil Fresle" <[EMAIL PROTECTED]>
Subject: Rijndael/AES VB Code
Date: Thu, 19 Apr 2001 23:24:13 +0100
Reply-To: "Phil Fresle" <[EMAIL PROTECTED]>
The code I originally posted on my site had a flaw in the 256 bit key
implementation. This has now been fixed in the version currently on my site
at http://www.frez.co.uk
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Thu, 19 Apr 2001 18:17:36 -0300
So if the probability of non-random is infinitesimal, why to try
statistical tests to prove truly randomness?
Statistical tests (Diehard, Maurer etc...), is it a loss of time?
Sincerely I do not understand.
I choose any bit-string I have 99.9999999 % that is purely random.
Why wasting time to find if it is random or not.
John Savard wrote:
>
> On Thu, 19 Apr 2001 14:38:17 -0300, newbie <[EMAIL PROTECTED]>
> wrote, in part:
>
> >If the message is 100101010
> >and the ouput 1111111111
> >you are quite sure to reject the "possible" key.
>
> The fraction of possible keys that are statistically nonrandom is
> nearly infinitesimal, and so this is unlikely to eliminate any
> possible plaintexts. Furthermore, it is generally considered an error
> when doing an OTP to reject random keys because they don't look
> random, although using a pad consisting of 0000000...0000 to encrypt a
> message would make all but the stoutest hearts quail. (We had an
> interesting debate on this issue some time ago.)
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Thu, 19 Apr 2001 22:27:52 GMT
"newbie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> So if the probability of non-random is infinitesimal, why to try
> statistical tests to prove truly randomness?
> Statistical tests (Diehard, Maurer etc...), is it a loss of time?
> Sincerely I do not understand.
> I choose any bit-string I have 99.9999999 % that is purely random.
> Why wasting time to find if it is random or not.
Why don't ya just read some books on the subject instead of constantly
randomly posting here? Obviously you are a clueless newbie, which is ok but
you have to learn to "learn".
Test's like Diehard look for particular types of flaws in particular prngs.
Most importantly some of tests look for flaws in lagged fibonacii generators
(birthday spacing).
Typically if your prng given say 20MB of output produces results that
diehard gives a p=1 or p=0 (or close too) then your PRNG is biased...
I know a few times it was usefull for detecting minute flaws in my homebrew
prngs...
Tom
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Thu, 19 Apr 2001 18:25:08 -0300
Do not forget that any plaintext is a determinstic sentence of "sense".
It is a long bit-string with a lot of constraints ( grammar, syntax,
sense, specific terms, specific patterns, etc...). It is builded
structure. You could still separate builded structure from random
sequence even if mathematically it is impossible.
Equality : random + structured text is not strictly = random.
Tom St Denis wrote:
>
> "newbie" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > You are reaching what I had tried to prouve.
> > You could distinguish with extra-information which message is valid.
> > And select the message. Because, the plaintext is deterministic
> > sequence.
> > If you could distinguish truly random output and not random, you have
> > still a way to break it.
> > I know it is very hard. Very very hard. It is like rebuilding the
> > plaintext with very few information.
> > I said OTP could be broken practically.
> > In theory, I KNOW that is unbreakable, but If you combine the context
> > factor and other extra-information you can break it.
>
> No you keep missing the important (I think you are ignoring my posts) facts.
> An OTP is not breakable under ANY circumstances. You can get the info it's
> hiding via other methods (i.e torture, just plain assuming the plaintext,
> likely to be wrong) but you cannot break an OTP.
>
> Just remember that there are lot of english sentences for a given n-char OTP
> message, all of which are equal probable.
>
> Just like (let's assume the message is zero padded or something)
>
> I WALKED MY DOG TODAY 0
> ME GOOD LIKE CAT 0
> NOBODY READS MY POSTS 0
>
> are all equal probable. There is no way to tell them from each other.
>
> Tom
------------------------------
From: "Robert M Best" <[EMAIL PROTECTED]>
Subject: Re: Crypto question
Date: Thu, 19 Apr 2001 12:34:01 -1000
> The best advice I can give is to use OAEP for encryption
> and PSS for signing.
I did a google.com search on "PSS signing" and found:
PSS = Probabilistic Signature Scheme
PSS = Private Secure Store
PSS = Provably Secure Signatures
PSS = EMSR3
Which one are you referring to?
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: OTP breaking strategy
Date: Thu, 19 Apr 2001 18:33:00 -0300
I know that.
But you have to read what I'm trying to say. Just decrypt what I'm
saying.
You are talking in theory.
I assume that I use extra-information.
I'm not dummy.
If all bit-string are truly random, even 1111111111111111111111111 or
000000000000 you should be right.
If all messages are related to the context, you should be right.
If all characters of the plaintext are not builded structure with its
own specificity, you should be right.
That is not what I'm talking about.
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (newbie) wrote in <[EMAIL PROTECTED]>:
>
> >So every bit-string is truly random.
> >
> >input : 10010101
> >ciphertext 10100101
> >output : 00110000
> >
> >this ouput is random?
>
> if your source of randomness is a true rand gerator
> then any output is possible. Including ouputs that
> contain long string of zeroes or ones or even simily
> asci text.
>
> if you want 80 bits out ten byte worth of data
> each of the possible 2**80 ouput strings has
> 1/2**80 probability of being picked
>
> if the message out for the first 8 bytes was
> "the dog " then there is a random string that could map it to
> "asdfgghi"
> however the message might have been
> "go home " then there is a random string that could map it to
> "asdfgghi"
> each random string is as possible as the other. If you
> used all of the possible "random string' the message could
> have been any thing for the first 8 bytes and still
> the cipher text could have been
> "asdfgghi"
>
> David A. Scott
> --
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
> http://www.jim.com/jamesd/Kong/scott19u.zip
> My website http://members.nbci.com/ecil/index.htm
> My crypto code http://radiusnet.net/crypto/archive/scott/
> MY Compression Page http://members.nbci.com/ecil/compress.htm
> **NOTE FOR EMAIL drop the roman "five" ***
> Disclaimer:I am in no way responsible for any of the statements
> made in the above text. For all I know I might be drugged or
> something..
> No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Shaft" <[EMAIL PROTECTED]>
Subject: Re: Crypto question
Date: Fri, 20 Apr 2001 00:42:08 +0200
well. new to, but will give it a go.
-it is no use using your public key to encrypt since the decrypting party
would need your private key. If they have that they can decrypt all messages
encrypted by that persons public key. Then your private key is compromised
and in essence useless.
-encrypting using private key is the second option, that is okay. Using a
pki infrastructure to encrypt whole messages is not the way it is usually
done. You use your private key to encrypt the hash and so generating a
digital signature. That way you keep a normal system (talking about servers
and stuff like that) performance instead of a server grasping for air in his
processor.
"Carsten Alexander" <[EMAIL PROTECTED]> wrote in message
news:9bl3l5$23te$[EMAIL PROTECTED]...
> > sender's *private* key? To put it another way, Alice encodes a message
> using
> > her *private* key and sends it to Bob. How can Bob decode that message
> using
> > Alice's *public* key? Is this normal? My understanding is that Alice can
> > only encode messages using Bob's public key, and Bob then will decode
that
> > message using his private key.
>
> Well, it may be somehow confusing, but the private key is called "private"
> not because it's a special key with a special structure. It's called
> "private" because the key is kept (at least is to keep) secret. Actually
> both keys depend on each other. But that dependency can not be deduced
> without some special information, which is also kept secret (or is
destroyed
> after the keypair was generated. Both keys can be used for encryption and
> decryption in the same way but with another intention.
>
> Someone can encrypt a message using your public key and only can decrypt
it,
> because your private key is kept secret. You can also encrypt a message
> using your own private key and that message can only be decrypted by using
> your public key. Since your private key is kept secret, you and only you
can
> encrypt it. If this encrypted message can be decrypted by using your
public
> key, it's the evidence that you encrypted that message.
>
> Got the big picture?
>
> --
> Carsten Alexander
>
>
------------------------------
From: "Ivo Brugman" <[EMAIL PROTECTED]>
Subject: Re: Crypto question
Date: Fri, 20 Apr 2001 00:43:05 +0200
well. new to, but will give it a go.
-it is no use using your public key to encrypt since the decrypting party
would need your private key. If they have that they can decrypt all messages
encrypted by that persons public key. Then your private key is compromised
and in essence useless.
-encrypting using private key is the second option, that is okay. Using a
pki infrastructure to encrypt whole messages is not the way it is usually
done. You use your private key to encrypt the hash and so generating a
digital signature. That way you keep a normal system (talking about servers
and stuff like that) performance instead of a server grasping for air in his
processor.
Ivo
"Carsten Alexander" <[EMAIL PROTECTED]> wrote in message
news:9bl3l5$23te$[EMAIL PROTECTED]...
> > sender's *private* key? To put it another way, Alice encodes a message
> using
> > her *private* key and sends it to Bob. How can Bob decode that message
> using
> > Alice's *public* key? Is this normal? My understanding is that Alice can
> > only encode messages using Bob's public key, and Bob then will decode
that
> > message using his private key.
>
> Well, it may be somehow confusing, but the private key is called "private"
> not because it's a special key with a special structure. It's called
> "private" because the key is kept (at least is to keep) secret. Actually
> both keys depend on each other. But that dependency can not be deduced
> without some special information, which is also kept secret (or is
destroyed
> after the keypair was generated. Both keys can be used for encryption and
> decryption in the same way but with another intention.
>
> Someone can encrypt a message using your public key and only can decrypt
it,
> because your private key is kept secret. You can also encrypt a message
> using your own private key and that message can only be decrypted by using
> your public key. Since your private key is kept secret, you and only you
can
> encrypt it. If this encrypted message can be decrypted by using your
public
> key, it's the evidence that you encrypted that message.
>
> Got the big picture?
>
> --
> Carsten Alexander
>
>
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
