Cryptography-Digest Digest #182, Volume #14 Thu, 19 Apr 01 12:13:01 EDT
Contents:
newbie: cryptanalysis of pseudo-random OTP? ("Osugi Sakae")
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: First cipher ([EMAIL PROTECTED])
Re: Rabin-Miller prime testing (Simon Josefsson)
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: Reusing A One Time Pad ("Tom St Denis")
Re: NSA-Endorsed Schools have a Mediocre Internet Presence (Richard Herring)
Re: NSA-Endorsed Schools have a Mediocre Internet Presence (Richard Herring)
Re: Reusing A One Time Pad (Jerry Coffin)
please help! ("Tom St Denis")
Re: CAST5 Implementation (Mark Wooding)
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: Prime Numbers Patterns? (Kent Briggs)
Re: Reusing A One Time Pad ("Tom St Denis")
Re: NSA-Endorsed Schools have a Mediocre Internet Presence (Richard Herring)
Re: First cipher ("Scott Fluhrer")
Monoalphabetic Substitution Cipher Cracker program ("Robert Reynard")
Re: Crypto question ("Shah Karim")
----------------------------------------------------------------------------
From: "Osugi Sakae" <[EMAIL PROTECTED]>
Subject: newbie: cryptanalysis of pseudo-random OTP?
Date: Thu, 19 Apr 2001 22:53:30 +0900
Reply-To: [EMAIL PROTECTED]
forgive me for what is prolly a newbie question, but ...
I understand that a properly impliemented and used OTP is secure, and I
understand that a simple polyalphabetic substitution with a keyword is
not secure, and in fact almost (totally?) worthless if computers are used to
attack it. Several of the intro to crypto books discuss this, right upto
keywords as long as the plaintext. (Forget whose, but one book mentioned
using a Carl Sagan book as the "keyword"). What they don't say is why
this is not secure, just that the language of the keyword rubs off on the
ciphertext. I can understand this, supposing that more of the plaintext
will get enciphered with the letter 'e' than with the letter 'q'. But how
would someone go about cryptoanalyzing this? The kappa test would tell
them that it is a polyalphabetic cipher, but what next? None of the books
I have read (and understood) goes into this.
The books also mention that a OTP is only as secure as the random number,
but again don't mention how someone would break a pseudo-random cipher.
Is it something to do with probabilities of subsequent numbers (for
example, noticing that say 5 tends to follow 8 more often than 10% of the
time? (assuming a cipher that displays as numbers 0-9))
Also, OTP's are hard to impliment, because of the amount of data and the
need for secure exchange and storage. And they work best with a limited
number of people.
So, thinking about these long keywords, OTP, and pseudo-random stuff,
I had an idea that I think i understand. (I am not suggesting this as a real
system, I understand that I am not qualified to declare any system secure
(of course, if I can break it, it is most likely very insecure). This is
just a thought exercise).
1. Take any previously agreed upon text - one from project gutenberg
would be good.
2. Just xor'ing with the text would not be secure, nor I gather would
doing some sort of transformation add all that much security.
3. So, tally the letters' frequencies. Choose the two letters that
account for the closest percentage of the text (4.021% and
4.074% for example).
4. Keep those two and get rid of the others. If it helps security, do
some simple transformation on the letters, either on the full text or on
the modified text consisting of only two letters.
5. Convert the two letters to 1 and 0. You now have a large number of
ones and zeros that can be used as binary input for xor'ing with the
cleartext. (8 digits from the pseudo-random file for each ascii character
in the plaintext).
How secure would it be? How random would the resulting pseudo-
random file be? How does one test this? How would one go
about attacking it? Would it be easiest just to keep a database of
stats for project gutenberg files?
It is a long key but has lost most of the linguistic traits that would
give it away, right? Aside from probable weak keys, would the fact that
such a pseudo-random number is not mathematically generated be an
advantage?
I guess what it comes down to is, would anyone like to comment on the
above and / or recommend some more advanced books or web sites dealing
with cryptanalysis of pseudo-random OTP? Or for that matter a good book
to help me get up to speed on the maths involved?
I've read:
The Code Breakers by Kahn (of course)
Cryptology by Beutelspacher
one or two other introductory books that I cannot recall at the moment
Decrypted Secrets by Bauer
Applied Cryptography by Schneier
Some parts of Schneier's book were hard to follow, but the math in
Bauer's book lost me. The others I think I understood properly.
yoroshiku (japanese for "please be nice to me")
--
Osugi Sakae
"I am not a number, I am a free man."
- the prisoner
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Thu, 19 Apr 2001 08:55:24 -0500
Thanks for the history lesson but my real "question" or curiosity was the
word origins. As best as I can tell "snake oil" came from "snake" for
someone wicked and deceitful, and "oil" from the fact that many "real" cures
of the time relied on varies natural oils and balms, like eucalyptus or
evergreen oil.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: First cipher
Date: Thu, 19 Apr 2001 05:13:45 -0800
Mark Wooding wrote:
>
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
[snip]
>
> > 2.) Key schedule to create 16 64-bit subkeys
> > a. Split key into two 64-bit subkeys (k1, k2).
> > b. To generate the next two subkeys, permute
> > k1, k2 then left circular shift (LCS)
> > the result of each permutation. The number of
> > shifts is determined by the value of two bits
> > (say b1,b0 for example) from the permutation output.
> > The result of the k1 permutation, LCS(b1,b0) becomes k3.
> > The result of the k2 permutation, LCS(b1,b0) becomes k4.
> > c. Repeat (b) until 16 64-bit subkeys are obtained.
> >
> > Is the LCS(b1,b0) necessary? I wondered if a simple permutation
> > would be sufficient since the key is assumed to be random and
> > secret...
>
> This is not a good idea. The problem is that you're using real key bits
> in the cipher. If an attack discovers some bits of a round key, it's
> actually found some real bits of the key, and therefore bits of other
> round keys. The rotations make life a little more difficult but not a
> lot. I think you want something with more one-wayness.
How does one find key bits in a certain round? The cryptanalyst doesn't
get to observe the results of the round. Even if he gets to choose
plaintext,
all he sees is the result of 16 rounds of this "dinosaur". Why isn't a
simple key schedule sufficient given that the key is assumed secret, and
the cryptanalyst must solve the entire problem at once (he can't look at
the result of individual rounds)?
[snip]
> Don't choose the S-box mappings completely at random. You need to
> design the S-box and permutation at the same time. The most difficult
> problem is that the F function as a whole can't be bijective. You need
> to ensure that the maximum probability of a differential x -> 0 through
> F is 2^-10 or less. That's a tall order. The fact that the expansion
> gives complete overlap (unlike DES, which has only 50% overlap) protects
> your cipher from t_i -> t_j differentials which are usually an inherent
> problem with DES-style S-P networks. A single-bit change in the input
> to F will definitely affect the input to two S-boxes.
>
It seems like an S-box design would have to be optimized against a
certain
type of attack and weak against other attacks, or is the S-box only
meant
to thwart a differential attack? Why must an S-box be bijective given
that the F function needn't be reversible?
> Good luck.
Thanks for your input.
>
> -- [mdw]
------------------------------
From: Simon Josefsson <[EMAIL PROTECTED]>
Subject: Re: Rabin-Miller prime testing
Date: 19 Apr 2001 16:23:21 +0200
"nospam"@"nonsuch.org" ("Bryan Olson") writes:
> >Even when generating keys yourself, prime "witnesses" is useful if you
> >don't completely trust the application or especially the randomness
> >source. IMHO applications should include a prime witness with primes
> >they generate, if for no other reason to prove the integrity of the
> >application and randomness source.
>
> I don't think so. There are short-certificates for
> primality, but the Miller-Rabin "witnesses" testify to
> composite-ness, not primality. I don't see what they have
> to do with the random source either; given insufficient
> entropy, the significant mode of failure is to produce
> predictable primes, not non-primes.
Sorry, I probably wasn't clear -- I meant that a witness to prove the
primality of the number generated should be included. A Miller-Rabin
"witness" would be quite useless, as you indicate.
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Thu, 19 Apr 2001 09:18:32 -0500
> The "reusing" scheme:
> Mark G. Wolf thinks it's realistically unbreakable
It's more than a scheme. If I had an "infinitely" large crypto-doodle pad,
or even a "very" large one, I could find sections of various sizes that
repeat or match, yet my security would not be compromised according to your
own belief. So what gives? Obviously it comes down to the predictably of
my use of it.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Thu, 19 Apr 2001 14:36:17 GMT
"Mark G Wolf" <[EMAIL PROTECTED]> wrote in message
news:9bms5e$1kl8$[EMAIL PROTECTED]...
> > The "reusing" scheme:
> > Mark G. Wolf thinks it's realistically unbreakable
>
> It's more than a scheme. If I had an "infinitely" large crypto-doodle
pad,
> or even a "very" large one, I could find sections of various sizes that
> repeat or match, yet my security would not be compromised according to
your
> own belief. So what gives? Obviously it comes down to the predictably
of
> my use of it.
No again you are missing the concepts here. In a t-bit pad a n-bit section
will match another section with a probability of 2^-n. So if you have a
2^400 bit pad the probability that you find matching 20 bit sections is
2^-20 and you should expect to see such "collisions" have 2^380 such
occurences.
So what?
(assuming my math is right... I just finished a reply to a stupid email so
my brain is on idle now...)
Tom
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: NSA-Endorsed Schools have a Mediocre Internet Presence
Date: 19 Apr 2001 14:46:09 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
> Frank Gerlach wrote:
> > Definitely true. According to the "Puzzle Palace", in the last 30 years
> > the NSA was unable to break into high-level soviet communications,
> > because they used One-Time Pads for really important stuff.
> > So the major target were third-world countries, who still believed in
> > the concept of an "unbreakable code" and often used cooked stuff from
> > companies like Crypto AG or even Engimas (!!), which they got from the
> > brits. Another target were european companies selling dual-use stuff to
> > libya, iraq and iran and did just not know Echelon.
> Look, that is mostly wrong, but I'm not in a position to
> say just where or how.
Then it's just his opinion against yours, except that large parts of
the statements above are public knowledge.
> You should not consider "outsider"
> books like The Puzzle Palace to give accurate "insider"
> information.
That much is good advice.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: NSA-Endorsed Schools have a Mediocre Internet Presence
Date: 19 Apr 2001 14:47:30 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
> Mok-Kong Shen wrote:
> > I think that the significance of that gap is also rapidly
> > decreasing with time, since the common people can, if
> > they want, now encrypt with such security that it is
> > almost certain that the agencies couldn't crack.
> Hm. Why are they still in business (with satisfied customers,
> apparently).
The primary purpose of any organization is to ensure its own
survival, whatever they tell the shareholders.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Thu, 19 Apr 2001 08:59:50 -0600
In article <9bcpb4$290q$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> Please don't bother telling me you can't reuse a one time pad.
>
> If I had a "large" one time pad and used random fixed size "chunks" of it to
> essentially generate other one time pads to encrypt the exact same message,
> what would be the relationship between the time (given a fixed speed of
> computation) to break the coded message and the size of the pad, the size of
> the chunks, and the number of times the pad is reused.
What you're creating here is a stream cipher. What you're calling
the "one time pad" is simply some of the steam cipher's internal
state. It's difficult to say a lot about the exact security without
knowing all the details of what you'd do. Basically, you need a
pseudo-random number generator that'll produce the place from which
you'll use the "chunk" of the pad that you use to encrypt a
particular message. That clearly needs to produce a large enough
range of numbers to allow you to use any part of the pad with equal
probability. It also needs to select parts of the pad randomly
enough that it's difficult for anybody to predict when a particular
part will be used again ("difficult" really meaning you hope they
can't ever do so at all).
Contrary to some other statements made here, the security of such a
system does NOT immediately go to zero. Rather the contrary, there
are lots of stream ciphers around, quite a few of which haven't been
broken, at least as far as is publicly known. While ciphers in the
civilian sector have tended more toward block encryption, the NSA and
such use stream ciphers quite a bit.
In short, there's nothing to prevent this from working, quite
possibly even working quite well. OTOH, it's clearly NOT a one time
pad, or anything really very similar to it -- it's nothing more or
less than a stream cipher with a large internal state. The "rules"
for getting security out of a stream cipher are different from those
for block ciphers, but with careful design and use, there's nothing
about the basic concept that prevents excellent security.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: please help!
Date: Thu, 19 Apr 2001 15:01:03 GMT
Would someone like to proof read my SAC paper? You have to keep the paper a
tad "private" until after I submit it. If you're a SAC referee please
ignore this :-)
I just need help proofing my paper!!! (not alot of crypto friends around
here to talk to in person)
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: CAST5 Implementation
Date: 19 Apr 2001 15:09:08 GMT
George <[EMAIL PROTECTED]> wrote:
> Hello everyone. I've been trying to implement CAST5, but I am obviously
> doing it incorrectly because the test vectors do not match up. I have
> looked at other source code examples and am having no success in finding
> my mistake(s). Could someone please post an extended vector test?
> (showing the values of the Kr and Km arrays when using a 128 bit key,
> what the values for the left and right halves shouldbe after each round,
> etc.) Thanks.
Wouldn't it be nice if everyone provided these for their crypto
algorithms?
The biggest pain is probably the key schedule, which is replaced by a
sensible one in CAST6. Oh, well. Here's the stuff for the 128-bit key
test from RFC2144:
key = 01234567 12345678 23456789 3456789a
round 0: km = bc173e26; kr = 15
round 1: km = 78a207ef; kr = 1b
round 2: km = ece0a7f5; kr = 01
round 3: km = 7cb0fb6b; kr = 05
round 4: km = a5d2d636; kr = 03
round 5: km = d78b9407; kr = 1f
round 6: km = 56c069d3; kr = 1f
round 7: km = 82e8240c; kr = 1c
round 8: km = 33543749; kr = 10
round 9: km = 8813d5c7; kr = 1f
round 10: km = b9fcd732; kr = 12
round 11: km = 59106b36; kr = 01
round 12: km = 496af1a9; kr = 1d
round 13: km = 18f8dc43; kr = 19
round 14: km = 8d9def0f; kr = 01
round 15: km = 83eda384; kr = 0f
plaintext: 01234567 89abcdef
round 1: 89abcdef 6e271b2d
round 2: 6e271b2d f772b12b
round 3: f772b12b a2a47840
round 4: a2a47840 c64d5213
round 5: c64d5213 74f553dc
round 6: 74f553dc 05479e28
round 7: 05479e28 e45481d1
round 8: e45481d1 ee778a34
round 9: ee778a34 5d380c49
round 10: 5d380c49 03e2a321
round 11: 03e2a321 a353838e
round 12: a353838e 48dfd8dc
round 13: 48dfd8dc 4da92274
round 14: 4da92274 dda981ac
round 15: dda981ac 847e44b2
ciphertext: 238b4fe5 847e44b2
round 1: 847e44b2 dda981ac
round 2: dda981ac 4da92274
round 3: 4da92274 48dfd8dc
round 4: 48dfd8dc a353838e
round 5: a353838e 03e2a321
round 6: 03e2a321 5d380c49
round 7: 5d380c49 ee778a34
round 8: ee778a34 e45481d1
round 9: e45481d1 05479e28
round 10: 05479e28 74f553dc
round 11: 74f553dc c64d5213
round 12: c64d5213 a2a47840
round 13: a2a47840 f772b12b
round 14: f772b12b 6e271b2d
round 15: 6e271b2d 89abcdef
plaintext: 01234567 89abcdef
-- [mdw]
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Thu, 19 Apr 2001 10:00:35 -0500
Oh your just jealous because I came up with a kool sounding name for a
reusable OTP. Thanks to you.
crypto-doodle pad
cryptodoodle pad
crypto-doodle pad
cryptodoodle pad
crypto-doodle pad
On April 18, 2001 idiot-savant Mark G Wolf coined the term crypto-doodle
pad.
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: Prime Numbers Patterns?
Date: Thu, 19 Apr 2001 10:01:05 -0500
Wizartar wrote:
> For an example of what I mean:
> All numbers ending in 0, 2, 4, 5, 6, 8, once you get above 9 are defiantly
> not a prime numbers. So only numbers ending in 1, 3, 7, 9 need to be
> tested. Are there any other common patterns, once you reach higher numbers?
One other I can think of is that if the sum of all the individual digits is
divisible by 3 then the whole number itself is divisible by 3 and therefore not
prime.
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Thu, 19 Apr 2001 15:13:32 GMT
"Mark G Wolf" <[EMAIL PROTECTED]> wrote in message
news:9bmuka$376s$[EMAIL PROTECTED]...
> Oh your just jealous because I came up with a kool sounding name for a
> reusable OTP. Thanks to you.
>
> crypto-doodle pad
> cryptodoodle pad
> crypto-doodle pad
> cryptodoodle pad
> crypto-doodle pad
>
> On April 18, 2001 idiot-savant Mark G Wolf coined the term crypto-doodle
> pad.
>
Hmm sure and I invented TC5 ... so what? I also noted flaws in Matsui
sboxes too... whoopy. I broke the original CAST too (certain weak keys).
WHO CARES?
Tom
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: NSA-Endorsed Schools have a Mediocre Internet Presence
Date: 19 Apr 2001 14:56:02 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Doug Stell ([EMAIL PROTECTED])
wrote:
> On Fri, 13 Apr 2001 11:48:08 +0200, Frank Gerlach <[EMAIL PROTECTED]>
> wrote:
> >To clarify my previous statement that the UKUSA spooks are the best in
> >cryptography, ...
> Keep in mind that they know everything that the academics know. They
> know more and don't tell the academics.
It's *assumed* that they know more. But whatever the "more" may
be, they have to generate it for themselves. If they really are
the best, then that's no problem. But to assume that they are the
best in order to justify this argument is begging the question.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: First cipher
Date: Thu, 19 Apr 2001 08:17:08 -0700
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Mark Wooding wrote:
> >
> > [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> [snip]
> >
> > > 2.) Key schedule to create 16 64-bit subkeys
> > > a. Split key into two 64-bit subkeys (k1, k2).
> > > b. To generate the next two subkeys, permute
> > > k1, k2 then left circular shift (LCS)
> > > the result of each permutation. The number of
> > > shifts is determined by the value of two bits
> > > (say b1,b0 for example) from the permutation output.
> > > The result of the k1 permutation, LCS(b1,b0) becomes k3.
> > > The result of the k2 permutation, LCS(b1,b0) becomes k4.
> > > c. Repeat (b) until 16 64-bit subkeys are obtained.
> > >
> > > Is the LCS(b1,b0) necessary? I wondered if a simple permutation
> > > would be sufficient since the key is assumed to be random and
> > > secret...
> >
> > This is not a good idea. The problem is that you're using real key bits
> > in the cipher. If an attack discovers some bits of a round key, it's
> > actually found some real bits of the key, and therefore bits of other
> > round keys. The rotations make life a little more difficult but not a
> > lot. I think you want something with more one-wayness.
>
> How does one find key bits in a certain round? The cryptanalyst doesn't
> get to observe the results of the round. Even if he gets to choose
> plaintext,
> all he sees is the result of 16 rounds of this "dinosaur". Why isn't a
> simple key schedule sufficient given that the key is assumed secret, and
> the cryptanalyst must solve the entire problem at once (he can't look at
> the result of individual rounds)?
Ah, but lets assume I have a differential attack that gives me a few bits in
the first and last round. Then, I effectively have a few bits in all the
rounds (your variable shifting confuses things a little, but not enough to
give an attacker any real problems). We can then use those few bits in all
the rounds to find a few more bits, and soon the attacker has them all...
>
> [snip]
>
> > Don't choose the S-box mappings completely at random. You need to
> > design the S-box and permutation at the same time. The most difficult
> > problem is that the F function as a whole can't be bijective. You need
> > to ensure that the maximum probability of a differential x -> 0 through
> > F is 2^-10 or less. That's a tall order. The fact that the expansion
> > gives complete overlap (unlike DES, which has only 50% overlap) protects
> > your cipher from t_i -> t_j differentials which are usually an inherent
> > problem with DES-style S-P networks. A single-bit change in the input
> > to F will definitely affect the input to two S-boxes.
> >
>
> It seems like an S-box design would have to be optimized against a
> certain
> type of attack and weak against other attacks, or is the S-box only
> meant
> to thwart a differential attack? Why must an S-box be bijective given
> that the F function needn't be reversible?
Well, it needn't (the F function in DES isn't reversible), but it's usually
a good idea. Otherwise, you tend to be vulnerable to differentials of the
form:
(0, X)
where one half has a zero differential, and the other half has a nonzero
differential. If, in your F function, the F function turns the X
differential into a 0 differential with probability p>0, then you have a two
round differential that starts with (0, X), and ends with (0, X) with
probability p.
Now, when DES was designed, they specifically considered this differential,
and made sure it couldn't be concatinated with itself. Of course, they knew
what they were doing...
--
poncho
------------------------------
From: "Robert Reynard" <[EMAIL PROTECTED]>
Subject: Monoalphabetic Substitution Cipher Cracker program
Date: Thu, 19 Apr 2001 11:45:13 -0400
I recently placed a copy of a Monoalphabetic Substitution Cipher Cracker
program on the Secret Code Breaker Online web site in the Codes section on
the download page. This Windows, C++ program package is available as a FREE
download. The program was written for the Secret Code Breaker Online web
site by Chris Card.
The program is a random KEY generator hill climber that uses frequency of
occurrence profile data for KEY scoring. The program has a provision for
creating frequency profiles for three, four, five and six letter groups. The
entire zip file package is primarily intended as a learning tool for
teenagers who are just getting interested in basic cryptanalysis. It is
capable of 'breaking' most monoalphabetic substition ciphers, either with
known correct word lengths (cryptograms) or with unknown word lengths.
Robert Reynard
Author, Secret Code Breaker series of crypto books for young readers (8-16
yr.)
Secret Code Breaker Online at ==> http://codebreaker.dids.com
------------------------------
From: "Shah Karim" <[EMAIL PROTECTED]>
Subject: Re: Crypto question
Date: Thu, 19 Apr 2001 10:45:50 -0500
So either the private or the public key can be used to decode a a message
encoded with the other. This was something I didn't catch from the RSA
specs.
Many thanks to all who replied.
"Shah Karim" <[EMAIL PROTECTED]> wrote in message
news:9bl0dm$[EMAIL PROTECTED]...
> OK I am a crypto newbie, and while doing some reading on public key
> cryptography and digital signatures, I ran into something which puzzles me
:
>
> Given:
>
> 1) In public key cryptography there are 2 keys, private key and public
key,
> and only the public key is published. So anyone can send a message to an
> intended recipient using that recipient's public key to encrypt that
> message. However, only the intended recipient can decode that message
> because they have the private key.
>
> 2) In sending a digital signature, the sender computes a message digest
from
> the message to be sent, using for example a one-way hash function. This
> digest is encrypted using the sender's *private* key, yielding a digital
> signature. This signature, along with the original message to be sent, is
> encrypted using the intended recipient's public key and sent.
>
> 3) The recipient uses his private key to extract the message and the
> encrypted digital signature. Now to verify the signature, the recipient
> decrypts it using the sender's *public* key, yielding the original message
> digest. He also takes the received message and computes the digest using
the
> same one-way hash function. Lastly he compares the two digests to make
sure
> that they match, ensuring the message has not been tampered with in
> transmission.
>
> The problem I have is where the receiver decodes the sender's digital
> certificate: How can the receiver decode something that is encoded with
the
> 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.
>
> Can anyone explain/ comment on this? Thanks.
>
>
------------------------------
** 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
******************************
