Cryptography-Digest Digest #50, Volume #13 Mon, 30 Oct 00 19:13:01 EST
Contents:
Re: Padding scheme? (Tim Tyler)
Re: Searching for a good PRNG (Tim Tyler)
Re: BEST BIJECTIVE RIJNDAEL YET? ("Brian Gladman")
Re: RSA block length (Bryan Olson)
Re: CHAP security hole question (Vernon Schryver)
Re: Psuedo-random number generator (Tim Tyler)
Re: Searching for a good PRNG (David Schwartz)
Re: Psuedo-random number generator (David Schwartz)
Re: Searching for a good PRNG (David Schwartz)
Re: BEST BIJECTIVE RIJNDAEL YET? (Tim Tyler)
Re: Cracking of MasterKey Completed (SCOTT19U.ZIP_GUY)
Re: Calculating the redudancy of english? (JPeschel)
Re: BEST BIJECTIVE RIJNDAEL YET? (SCOTT19U.ZIP_GUY)
Re: Padding scheme? (SCOTT19U.ZIP_GUY)
Re: ciphertext smaller than blocksize ([EMAIL PROTECTED])
Re: how do you decrypt something encoded by C=M^e(mod N) (Sundial Services)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Padding scheme?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 30 Oct 2000 23:02:30 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
: SCOTT19U.ZIP_GUY wrote:
:> The other error I feel that is there is when you start doing this
:> for real the field you use to contain the data must be able to account
:> for all bit patterns you still have to play same games with this so
:> that every combination of bits is possible. Even if you try to add a
:> constant to a file the way I did there are optimal end considerations
:> that come out in the details.
: Clearly you are the type of person, who, if given a large bottle of
: "clue musk," could not get a clue.
The method described mainly works OK on this front - if you have some
trusted source of random numbers and are prepared to bulk up the resulting
files by a small quantity.
There are some problems if the distribution of files is such that the
number of files of each length are not equal. If (for example) 1 byte
files are the most common, then 2-byte and so on, then the representation
of the number of bits of padding is likely to exhibit bias - if a number
of such files are looked at.
I believe this is both undesirable and avoidable - however it is a
relatively minor issue.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Searching for a good PRNG
Reply-To: [EMAIL PROTECTED]
Date: Mon, 30 Oct 2000 23:05:08 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] wrote:
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : Tom=E1s?= Perlines 1Hormann <[EMAIL PROTECTED]> wrote:
:> :> I am searching for a good PRNG in software, preferrable for FREE.
[...]
:> :> Does anybody know a good URL???
:>
:> : http://www.fourmilab.ch/hotbits/generate.html
:>
:> : :-)
:>
:> That may be a good URL - but to save people visiting it
:> unnecessarily, it is linked to a hardware RNG which you can access
:> over the web.
: What is your point?
I thought I had expressed it clearly. What is in need of clarification?
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ ILOVEYOU.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: Mon, 30 Oct 2000 23:17:45 -0000
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Brian Gladman) wrote in
> <kmkL5.4161$zO3.132848@stones>:
>
> >
> >"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> [EMAIL PROTECTED] (Brian Gladman) wrote in
> >> <XUhL5.4086$zO3.128477@stones>:
> >>
> >> >I certainly did not claim that the length is 'added' to the file -
> >> >what I said was that it was encoded in the file, which is quite
> >> >different. Moreover, while the encoding adds no _data_ , it certainly
> >> >adds _information_ since the file length could not be recovered if it
> >> >did not.
> >> >
> >> > Brian Gladman
> >> >
> >>
> >> Your wrong the lemght info is not encoded in the file. You can
> >> change
> >> the bits in the file to anything you want and the lenght would not
> >> change. The length that the operating system allocates for the file is
> >> something different. The data encrypted is the file data. Nohting in
> >> that data has any need for a length encoding.
> >
> >There are two situations that are possible:
> >
> >(a) I can recover the exact original file from its compressed form and
> >then measure the length of the resulting file;
> >(b) I cannot accurately recover the original file and hence cannot
> >determine its length.
> >
> >If (a) applies I have an algorithm for determining the original file
> >length when given only a compressed version of the file so this
> >information must be encoded somewhere in the latter.
> >
> >If (b) applies then the compression scheme is lossy and I am no longer
> >interested in it
> >
> >So which is it - (a) or (b)?
> >
> > Brian Gladman
> >
> >
> >
> >
>
> From the constraint you out it in.It is like is light a wave or
particle.
> Or have you stopped betting your wife. Or who cuts the babers hair when
> the barber only cuts those who don't cut there own hair.
>
> Here is a better realy world example. My bijective compression routine
> is the identiy transform. I am compressing one byte files. I compress
> each of the 256 possible files. I got 256 files out. where in any of
> these 256 files is the lenght encoded. No where! the operating system
> has allocted the lenght. I'm free to choose what;s in the files. If you
> can't see this your not intelligent to carry the conversation on and
> I am done since I don't think any one following this thread thanks
> you have a point at all.
If you track back you will find that we are not talking about your scheme
but rather Matt's scheme and the issue of whether or not compressed files in
his scheme contain an encoding of the length of the uncompressed file.
It is always a sign that a person's argument is weak when they find it
necessary to depart from logic and resort instead to insulting remarks about
others who are engaged in the debate.
It is also interesting to observe that your spelling gets worse when you get
angry. I think you should cool down before you have a heart attack.
Brian Gladman
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: RSA block length
Date: Mon, 30 Oct 2000 23:13:03 GMT
[EMAIL PROTECTED] wrote:
> I am converting each character of plaintext into an integer and
> encrypting(RSA) each individual integer. Is this best practice, or
> should i use a longer block length?
Current best practice for RSA encryption is OAEP
(Optimal Asymmetric Encryption Padding). The specific
standard is on-line in PKCS-1. See:
http://www.rsasecurity.com/rsalabs/pkcs/pkcs-1/index.html
Most implementations encrypt a symmetric key with RSA, and
then use the symmetric key for bulk data encryption.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: CHAP security hole question
Date: 30 Oct 2000 10:25:58 -0700
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
> ...
>FWIW I have read the papers describing this system and I have found no
>false claims on the IntegritySciences web site. I don't like software
>patents and would prefer to go with a system like SRP
>(http://www.srp.stanford.edu/)
www.srp.stanford.edu does not result resolve (at least for me),
but http://srp.stanford.edu/ works.
> which according to the author can be used
>without licensing anything, but DPJ is certainly right to state the
>difference between weak password systems like CHAP and strong ones like
>B-SPEKE and SRP as strongly as he does. I can understand why the claims
>seem literally too good to be true, but having looked into them I find
>them hard to disbelieve. And if you have enough number theory to
>understand how RSA or Diffie-Hellman work then understanding B-SPEKE
>shouldn't be that much harder.
For some appliations, EKE and SRP sound be good, but that faint praise
is unfair. The problem with the other web pages is like that of the
"unbreakable one time pad" systems based on psuedo-random number
generators. It's not that the underlying ideas are other than very
interesting, but that they are so oversold and sold for the
wrong applications that they become mere coloring agents in "breezy
discussions" using "laymen terms to generate excitement."
There is a problem unrelated to presentation with schemes with the aim in
http://www-cs-students.stanford.edu/~tjw/srp/whatisit.html
SRP is a secure password authentication protocol. It solves the
problem of authenticating clients to servers securely, in cases
where the client must memorize a small secret (like a password) and
carries no other secret information, and where the server carries
a verifier which allows it to authenticate the client but which, if
compromised, would not allow someone to impersonate the client.
That problem is that description applies when a human needs to memorize
a single password. Set asside the fact that much authenticating involves
two computers, no humans, and so much less need for ideas like EKE and
SRP. (Computer can memorize secrets that are immune to dictionary attacks,
and nothing can be done to completely protect computers from having their
memories opened and their secrets read.)
Many people now should have many distinct passwords, and eventually most
will need many passwords. You need a password for each of many web sites,
from newspapers to stock brokers to merchants and banks. It would be even
worse to use a single common password that to write down a bunch. So what
can you do? You can use a a few shared passwords for throw-away accounts
such as free newspapers, but you really shouldn't share a password among
your 401K, on-line bank, medical, and stock broker accounts. You could
buy PKI snake oil and put all of your authentication eggs into a PKI
vendor's single basket, but people who think see that PKI can reduce the
number of secrets but not enough to be managable by most human memories.
A reasonable smart card containing passwords would solve such problems
better than zero knowledge schemes. The problem of authenticating the
user to a smart card is nontrivial, and never mind whether it would
involved biometrics, a 100 digit PIN, or one of the zero knowledge schemes
that do not require computers at both ends. There's also the problem of
losing the smart card. Still, a smart card containing dozens of good
(big) passwords makes far more sense than using SRP or EKE to let one to
use dozens of poor passwords kept straight in human memory.
In the long run, perhaps smart cards will contain GBytes of stable
storage, have heads-up displays, and be called PC's.
In other words, there are good reasons why zero knowledge schemes have
not taken the Internet by storm, but are far from cutting-edge brand new
(contrary to Integrity Sciences). That doesn't mean they're not valuable,
just as the snake oil from the "unbreakable one time pad random number"
vendors does not imply that every encryption scheme other a one time pad
is junk.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Reply-To: [EMAIL PROTECTED]
Date: Mon, 30 Oct 2000 23:13:43 GMT
David Schwartz <[EMAIL PROTECTED]> wrote:
: Terry Ritter wrote:
[consider true quantum randomness in the offsets between the CPU
oscillator and the clock oscillator on a network card. This can be
measured in software.]
:> Oh, please. Your claim was for "true quantum randomness." If you had
:> that sort of randomness you would not need an MD5 checksum.
: That's nonesense. Suppose I had a stream of bits where one in a million
: of them were zeroes and the rest were ones. Suppose which ones were
: zeroes and which were ones was due to true quantum randomness. You could
: still predict the bitstream contents correctly all but one-in-a-million
: times just be saying they're all zeroes. The MD5 sum ensures that the
: entropy is distributed over all the bits evenly.
If you're involving MD5 any claim for "true randomness" is moot - the
result will not be balanced and won't have exactly maximal entropy -
even if the inputs are perfectly random.
In what sense is such randomness "true"? ISTM that there will
be some remaining predictable component.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Searching for a good PRNG
Date: Mon, 30 Oct 2000 15:26:28 -0800
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > Tom St Denis <[EMAIL PROTECTED]> wrote:
> > : Tom=E1s?= Perlines 1Hormann <[EMAIL PROTECTED]> wrote:
> >
> > :> I am searching for a good PRNG in software, preferrable for FREE.
> [...]
> >
> > :> Does anybody know a good URL???
> >
> > : http://www.fourmilab.ch/hotbits/generate.html
> >
> > : :-)
> >
> > That may be a good URL - but to save people visiting it
> unnecessarily, it
> > is linked to a hardware RNG which you can access over the web.
>
> What is your point?
The point is that this is great for statistical randomness but useless
for cryptographic randomness.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Mon, 30 Oct 2000 15:34:04 -0800
Tim Tyler wrote:
>
> David Schwartz <[EMAIL PROTECTED]> wrote:
> : Terry Ritter wrote:
>
> [consider true quantum randomness in the offsets between the CPU
> oscillator and the clock oscillator on a network card. This can be
> measured in software.]
>
> :> Oh, please. Your claim was for "true quantum randomness." If you had
> :> that sort of randomness you would not need an MD5 checksum.
>
> : That's nonesense. Suppose I had a stream of bits where one in a million
> : of them were zeroes and the rest were ones. Suppose which ones were
> : zeroes and which were ones was due to true quantum randomness. You could
> : still predict the bitstream contents correctly all but one-in-a-million
> : times just be saying they're all zeroes. The MD5 sum ensures that the
> : entropy is distributed over all the bits evenly.
>
> If you're involving MD5 any claim for "true randomness" is moot - the
> result will not be balanced and won't have exactly maximal entropy -
> even if the inputs are perfectly random.
Who said anything about being balanced or having exactly maximal
entropy? I'm talking about having sufficient entropy for cryptographic
purposes, nothing more, nothing less.
> In what sense is such randomness "true"? ISTM that there will
> be some remaining predictable component.
The issue is not whether there is any predictable component, the issue
is whether there is any unpredictable component. If you can get any at
all, you can get as much as you want by simply repeating the process.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Searching for a good PRNG
Date: Mon, 30 Oct 2000 15:40:35 -0800
I like this quote too:
"In practice, to avoid any residual bias resulting from non-random
systematic errors in the apparatus or measuring process
consistently favouring one state, the sense of the comparison between T1
and T2 is reversed for consecutive bits."
How can XORing a bit stream with a known sequence of bits make it any
more or less random?
DS
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 30 Oct 2000 23:29:09 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] (John Savard) wrote in
: <[EMAIL PROTECTED]>:
:>Here I am in difficulty in understanding the specifics, but I think I
:>may be more in agreement with Mr. Tyler here. In fact, this is
:>precisely the point on which I've found Mr. Scott's bijective scheme
:>flawed when he converts a compressed file to one with a length that is
:>an integer number of octets.
: What you fail to understand is that it is not a flaw.
I was under the impression that your original Huffmann compression routine
exhibited a bias in the final byte, when applied to sets of random inputs
(e.g. usenet news messages).
This meant that the last bits were more likely to be zeros than ones.
I tested it to see if this was the case, and observed this effect.
I regard this as a flaw - and it is a problem that John's scheme
avoids.
After some reflection, I believe the problem is specific to your ending
method - I don't think other 1-1 methods are necessarily flawed in the
same way.
:>A file indeed has length as one of its properties. If you add bits to
:>a file which encode its length, and then encrypt the result, you
:>haven't added _information_ to the file, but precisely because you
: That is where your logic is wrong. If your add bits to a file you
: do add information to a file that can be exploited.
This isn't information in the traditional sense of "suprise value".
Someone with the file already knows how long it is. If you append
the length of a file to a file 1000 times, that adds precious little
information that was not already known. John's use of "information"
is quite orthodox.
:>Thus, I've noted that the standard technique of including length
:>information in a file before encryption would be, where compression
:>produces a file with an arbitrary length in bits, but the file is to
:>be, for whatever reason, padded out to whole bytes before encryption
:>(presumably for convenience in programming) is: add _exactly three_
:>bits to the file, to give only the information of the file's length
:>modulo 8, and then _destroy_ the other "copy" of that information by
:>padding the file with random bits.
: The fact is this is not needed [...]
That appears to be true. It adds up to 8 bits unnecessarily,
and requires the use of a genuine random number generator.
Apart from these points, it has the virtue of being quite simple.
:>From his descriptions of his scheme - despite his pleas, I have not
:>considered it worthwhile to delve into his C code - it appeared to me
:>that what he was proposing for "Bijective Huffman" was equivalent to
:>the standard hash function technique of padding with 1000...000. Which
:>does create a unique encoding, but which is biased [...]
Scott's code is vastly more sophisticated than that.
You can read a description of what he did (without looking at his code)
by visiting http://members.nbci.com/_XOOM/ecil/compres1.htm
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ ILOVEYOU.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Cracking of MasterKey Completed
Date: 30 Oct 2000 23:46:29 GMT
[EMAIL PROTECTED] (JPeschel) wrote in
<[EMAIL PROTECTED]>:
>SCOTT19U.ZIP_GUY writes:
>
>>I would like your and
>>or his opinion of Matts bijective bicom program.
>>
>
>I haven't looked at it. But you really don't need my
>comments, as you have all the birds chirping about
>it now. :)
But I think we disagree heavuly on many things. But in your
own way you try to be some what fair. I could use your views
as a reference point. I know Tommy is clueless and feel he may
be in his fake ID mod. But I am still am amazed at how few people
seem to not understand what he did. Unlesss they plan to steal it
and take credit for it at a later time.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Calculating the redudancy of english?
Date: 30 Oct 2000 23:57:35 GMT
Simon Johnson [EMAIL PROTECTED] writes:
>What is the index of coincidence, Applied crypto doesn't seem to give
>enough info for me to estimate the redudanct of english.
The index of coincidence is a statistical measure of
the redundancy of text. Around 1920, William Friedman
published the article, "The Index of Coincidence and
its Applications in Cryptography."
http://www.aegeanparkpress.com/books_by_author.html
The expected IC of English is around .667.
Instead of trying to write the equation here,
I'll refer you to:
http://members.fortunecity.com/jpeschel/gillog1.htm
where you'll find the equation.
On this page, Jim uses the IC to do a ciphertext-only
crack of Enigma messages.
You'll also find C source for an IC program on the
"Historic" page of my web site.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: 30 Oct 2000 23:52:47 GMT
[EMAIL PROTECTED] (Brian Gladman) wrote in
<yenL5.4249$zO3.139556@stones>:
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>
>> Here is a better realy world example. My bijective compression
>> routine
>> is the identiy transform. I am compressing one byte files. I compress
>> each of the 256 possible files. I got 256 files out. where in any of
>> these 256 files is the lenght encoded. No where! the operating system
>> has allocted the lenght. I'm free to choose what;s in the files. If
>> you can't see this your not intelligent to carry the conversation on
>> and I am done since I don't think any one following this thread thanks
>> you have a point at all.
>
>If you track back you will find that we are not talking about your
>scheme but rather Matt's scheme and the issue of whether or not
>compressed files in his scheme contain an encoding of the length of the
>uncompressed file.
>
Our schems as you call them are basically the same. So when one
talks about optimal end handling and endcode lengths
there is no difference and I see you did not understand
my anwser
>It is always a sign that a person's argument is weak when they find it
>necessary to depart from logic and resort instead to insulting remarks
>about others who are engaged in the debate.
>
No asshole it what happens when one trys to explain something simple
to an idot who refuses to understand. But I guess you can't understand
that
>It is also interesting to observe that your spelling gets worse when you
>get angry. I think you should cool down before you have a heart attack.
>
Yes its hard to soar with eagles when your stuck talking to
turkeys.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Padding scheme?
Date: 30 Oct 2000 23:40:54 GMT
>Although it's true that using bits from a hash, rather than bits from a
>TRBG, does create a bijective mapping from the set of messages whose
>lengths are multiples of 8 bits to the set of messages whose lengths are
>multiples of 128 bits, there is no significant difference in security
>between the original 1-to-many mapping and the hash-based 1-to-1
>mapping. The only security advantage of the change is that it closes
>off a possible subliminal channel. Nothing more, nothing less.
>
Not only is what you said not true but unless you give more detail
I am not sure you even have a bijective transoformation to from the
plain text to you 128 bits. I only said it could be done. Not that
you have code to actually do it.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ciphertext smaller than blocksize
Date: Mon, 30 Oct 2000 23:48:28 GMT
[snip my statement that the entropy of the key is diffused into the
plaintext in the creation of the ciphertext]
> I see your mind is still all messed up. You use the 'KEY" to encrypt
> a file. It does not create a file that is composed of a "key and the
> data" you don't know what your talking about. The key is no more a
> part of the file than a key is a part of a lock. THe key is used to
> transform the file. IN no way should it be combined with the encrypted
> data.
You are obviously lacking in any knowledge in this field. Let's begin
with just a sketch of a proof:
P=plaintext
K=key
C=ciphertext
Under a chosen cipher
C := effect of K on P
Since there's more than 1 possible value for the triple (K, P, C) for
each value of P the entropy of K chooses which value of C is obtained.
Therefore the entropy of K MUST be be either added or subtracted from
P to form C.
Since the choice of the pair (K, C) also selects the triple (K,P,C)
(the encryption is invertable), and K is chosen independently of the
pair (C,P), K cannot be used to remove entropy from P to form C.
The only solution remaining is that the entropy of K must be in some
form present in C after the transform from P.
That should be simple enough for even your meager mind to follow. Would
you by any chance care to change your opinion, or would you like to try
to prove mathematics wrong?
Joe
(that guy that keeps confusing you with facts)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 30 Oct 2000 17:07:52 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: how do you decrypt something encoded by C=M^e(mod N)
This is the RSA patent, and here's the trick. The values used for
encryption are the "public" key and these, ostensibly, cannot be used to
decipher the message.
The only key that can decipher is the companion "private" key.
And here's the real trick: supposedly you cannot compute the "private"
key given only the "public" key, although you can go the other way.
So to prepare the cryptosystem for use, one party dreams up a "private"
key, calculates the "public" key from it, and makes the public key known
to the world.
Anyone can now send a message to that person, although the message, once
enciphered, can only be recovered by the recipient, who has the private
key.
>Pepitoe wrote:
>
> I don't know if im posting in right place, i have very little knowledge of
> cryptography, but was interested in what i saw on a tv programme last night
> (ch4 the science of secrecy if anyone english is reading), they gave C=M^e
> (mod N) as a method of encryption where c is obviously the encrypted output,
> m is letter's value, n is multiple of keys and e seemed to be just a chosen
> power. I can understand how to use this to encrypt but i didn't see how to
> decrypt, and my knowledge of maths so far (not finished a level yet) doesn't
> let me work it out for my self (its probably simple but im not that
> clever!). So please explain a way to decrypt, if possible e-mail me
> [EMAIL PROTECTED] as i may not get a chance to visit this newsgroup
> again in time to read any replies.
>
> Thanks for your help
> Pepitoe
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
