Cryptography-Digest Digest #593, Volume #11 Fri, 21 Apr 00 08:13:00 EDT
Contents:
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: SSL and "man in the middle" attack (Jonathan Thornburg)
Sophie-Germain and ElGamal ("falissard")
Re: SSL and "man in the middle" attack (Francois Grieu)
Re: Des S-Boxes (Hideo Shimizu)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Tom St Denis)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Tom St Denis)
Contract signing via cryptographic means (HCI SysAdmin)
Re: password generator (Tom St Denis)
Re: The Illusion of Security (Tom St Denis)
Problems with OAP-L3 (Tom St Denis)
Re: New version of MIRACL (Tom St Denis)
Re: Sophie-Germain and ElGamal (Tom St Denis)
nss (elise)
Re: Newbie question (Sean Glazier)
Re: Newbie question (Sean Glazier)
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Fri, 21 Apr 2000 01:48:08 -0700
James Felling wrote:
>
> > <giant snip>
> >
> > I will prove you do not know what you are talking about by you
> > simply answering this question:
> >
> > The OAP-L3 encryption software uses a random number generator.
> > Now which of the following is the most correct and most
> > comprehensive description of this random number generator that
> > it uses: which is the description that results in the random
> > numbers used in the encryption process?
>
> >
> > 1) The process that outputs the random digits from the MixFiles,
or
> >
> > 2) the process that results in the OTP files?
>
> Well the best way to answer that is "neither"( or "both" -- depends
upon how I look at it). I
> agree that the stream data is generated primarially by process #2.
However it still uses
> data from process #1 to produce the mix files which are then used by
process #2. If one
> examines the crypto literature you will find many algorithims that
have comentaries by skilled
> people along the line of "this section of the algorithim is weak --
it does not do X properly
> -- I have found no attack to exploit this property" and this is
enough to withdraw the
> algorithim from serious consideration. Why should your program be
judged upon a different
> standard?
>
> >
> >
> > Now define precisely what your supposed flaws are and what is the
> > exact nature of these "artifacts" you allege?
>
> Ok since you have obviously not done even a textbook analisys of your
mix file generation
> process I will.
> I am using your own names for the subprocesses.(P.S. this is not an
exhaustive list of what I
> have found, but it is simply the result of a half hour of simple
kindergarten cryptoanalisys)
>
> We start with a file F of all possible 1 to 10 sequences.I shall
number them F(1),F(2),
> ....,F(10!)
>
> 1) Scramble -- since all other mixing ops are external( they affect
the order in which the
> F(i)'s are presented) Scramble is effectively orthogonal to all other
MixFile creation
> steps.This means we can effectivly treat all other steps as modifying
the set S=
> Scramble(F(1)), Scramble(F(2)), ....., Scramble(F(10!))
>
> 2) Mix -- The "Mix" operation doesn't do a very good job of it. M(i)=
the ith sequence of
> Mix(S) has the following properties M(j+105*n)= S(j+105*n) with
probability . (n>=0, and j=
> first mix value). Since there are further steps this is less bad than
it seems.
>
> 3) Redistribute -- This creates 14 files I will denote them as T(1)
to T(14), and then T(k,m)
> = themth member of Tfilek.
> This is aparently accomplished as follows T(k,m)= M( (k-1)*259200 + m
).
>
> 4) Shuffle. This Permutes the Tfiles, then data are taken from them
in the permuted order to
> generate the mixfile.call this permutation p(x).
>
> Attack vs mix file generation.
>
> Sincej>=1, T(1,1)= Scramble(F(1)) , and T(8,1)=Scramble(F(1814401))
this meand that within
> the first 14 sequences in the Mix files we have two sequences that
are known, this will occur
> regularly within the mix file where within 14 digits at easily
computable points in the file 2
> sequences (Scrambled) with known chjaracter exist. Because of this we
have very good odds of
> recovering both scramble, and some very good information on P(x) in
addition. Further, if
> j>1 we will easily recover scramble as T(1,2) will occur 14 spots
later in the file and will
> be a single rearangement swap different from T(1,1)
> .
>
> As you can see the Mixfile.otp has a significant amount of
exploitable structure -- enough to
> allow recovery of its generating keys in comparitively short order.
Since this is the case,
> it seems likely to me that at least some of this structure could be
exploited by an analyst
> working the whole key backward.
>
> >
> >
> > Let me end with this:
> >
> > The accepted test of the security of an encryption process is not
> > what Mr. Huuskonen has asked for. The accepted test is that it is
> > assumed that the cracker knows every thing there is to know about
> > the algorithm, and that the cracker has a substantial amount of
> > plain text and the corresponding encrypted text. From this
> > it is demanded that the cracker use this information and knowledge
> > to crack the software. This is hardly what Mr. Huuskonen is asking
> > for: he is essentially asking for the key once removed.
>
> Yes, to a degree he is. But the same structures that allow him to
attack your mix file will
> exist, to a lesser degree in the final output. My guess is that the
Mix files provide about
> 20-30 bits of randomness per each(assuming my attack cannot be
refined). This puts the
> randomness of your code somewhere in the neigborhood of a 90 to 100
bits( tops) when you
> factor it all in. I will be generous and say you are as secure as
3DES(112 bits). Why should
> we use your code in prefrence to 3DES?
This is nothing but BS and I think you know it.
Let's keep it simple then build from there.
Let's say we start with the original encryption data file: the
3,628,800 ten-digit permutations consisting of the digits 0 - 9
with no repeats. In this original encryption file the permutations
are arranged in ascending order.
Let's just run the Shuffle process once. The first 259,200 arrays
are read from the original encryption data file and written to
TFile1. The next 259,200 arrays are read and written to TFile2.
The next 259,200 arrays are read and written to TFile3, etc. until
there are TFile1 - TFile14.
The user then inputs a true random 14 number sequence of the
numbers 1 - 14 with no repeats. For your information there are
14! = over 87 billion possible unique sequences of the numbers
1 - 14.
Then these 14 TFiles are interleaved one array at a time according
to this 14 number sequence.
The resulting output file, we'll call it, MixFile1, is one of over
87 billion possible.
You say it will be easy to guess the order of the permutations in
this MixFile1? How will you do it? There is only one way to do
it: trial and error by using all the 87 billion 14 number
sequences. (Because the input was true random you cannot get around
this by any other means.)
So, after you have produced each of these over 87 billion possible
MixFile1's you store them confident that you have certainly produced
the correct MixFile1 among the over 87 billion you have generated and
stored.
Okay.
Now let us run the Shuffle process again on MixFile1 using another
true random 14 number sequence of the numbers 1 - 14 with no repeats
and call the output again, MixFile1. As above, there are over 87
billion possible sequences.
But there are now over (87E9)^2 possible 28 number sequences of two
sequences of 14 numbers 1 - 14 in a row.
So now you have to produce and store over (87E9)^2 MixFile1's but
you can still be certain that at least one of these (87E9)^2
MixFile1's is the correct one.
Let's say I repeat the process 50 times in total. This means that I
have shuffled the original encryption data file 50 times using one
of over 87 billion 14 number sequences with each shuffle. Thus the
total user input is 50 true random 14 number sequences of the numbers
1 - 14.
This means that there are over (87E9)^50 possible 50 true random 14
number sequence sequences in a row and that the actual input used is
only one of these over (87E9)^50 sequences.
For you to determine the final MixFile array sequence after 50 runs
of the Shuffle process with absolute certainty that at least one of
the MixFiles is the actual one, you will have to produce over
(87E9)^50 MixFiles, and store them.
Let's see, if each MixFile is over 18MB you will need enough storage
for 18E6 * (87E9)^50 = 1.5E459 bytes.
But you can at least be sure you have the right sequence somewhere
among them all.
Your problem now is: which one is it?
Let's say you need three such MixFiles and that the user uses their
last MixFile1 after 50 Shuffle runs to begin 50 more shuffle
processes to produce a MixFile2, then run 50 more processes on this
last MixFile2 to produce a MixFile3.
Similarly as shown in the Theory and Processes Help Files, the odds
of duplicating MixFile1 with certainty is one in (87E9)^50.
But for duplicating MixFile2 it is one in ((87E9)^50)^2 = (87E9)^100.
For duplicating MixFile3 it is one in ((87E9)^50)^3) = (87E9)^150.
And finally, to guess with certainty, all three MixFiles it would be
(87E9)^50 * (87E9)^100 * (87E9)^150 = (87E9)^300.
Tell us how you are going to guess the one chance in (87E9)^300 of
getting the correct three exact MixFiles? (Not to mention store all
of them.)
We really want to know?
Give up?
Give up.
And we haven't even considered subsequent processing of the random
binary number files produced from the MixFiles.
Now, what is it you don't understand about unbreakable?
(I bet you would you like me to sneak you the key right about
now, eh?)
See, how plain it is in layman's terms. This is why I say that the
entire software package is understandable by anyone with average
intelligence.
Now what exactly don't you understand?
(And whatever it is you'd like to say can you say it in laymen's terms
so everyone can understand you?)
Thank you.
(All of this is just as simply explained in the Help Files at
http://www.ciphile.com)
------------------------------
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Subject: Re: SSL and "man in the middle" attack
Date: 21 Apr 2000 10:59:44 +0200
In article <mBUL4.9721$[EMAIL PROTECTED]>,
Lyalc <[EMAIL PROTECTED]> wrote:
> Web Spoofing: An Internet Con Game
> Edward W. Felten, Dirk Balfanz, Drew Dean, and Dan S. Wallach
> Technical Report 540–96 (revised Feb. 1997)
This (excellent) report is online at
http://www.cs.princeton.edu/sip/pub/spoofing.html
Enjoy,
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
Q: Which countries [only 5 of them] have the death penalty for children?
A: Iran, Nigeria, Pakistan, Saudi Arabia, and United States
------------------------------
From: "falissard" <[EMAIL PROTECTED]>
Subject: Sophie-Germain and ElGamal
Date: Fri, 21 Apr 2000 11:44:19 +0200
For DH-ElGamal encryption, some people recommend
using particular prime numbers (Sophie-Germain primes,
where both p and (p-1)/2 are prime).
See for example http://www.gnupg.org/rfc2440-12.html
I am not sure PGP in its current version makes any use of
Sophie-Germain primes.
What could justify using them, from a cryptanalysis point of view?
http://os390-mvs.hypermart.net
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: SSL and "man in the middle" attack
Date: Fri, 21 Apr 2000 12:21:55 +0200
Thanks to Lyalc <[EMAIL PROTECTED]> and
Jonathan Thornburg <[EMAIL PROTECTED]>
for pointing
> Web Spoofing: An Internet Con Game
> Edward W. Felten, Dirk Balfanz, Drew Dean, and Dan S. Wallach
> Technical Report 540–96 (revised Feb. 1997)
> at <http://www.cs.princeton.edu/sip/pub/spoofing.html>
The paper however does not discuss how SSL is affected.
I believe in theory it might be possible to guard against spoofing, but
a lot of assumptions have to be made, including
- software on the user's PC is trusted
- user can appropriately decide to disclose credit card info or not on
the basis on the merchant's identity as displayed by the trusted software
- user can distinguish between such trusted display from display
generated by untrusted sources (e.g. GIF, javascript..)
Clearly, only a tiny minority of web users are in this situation, but at
least large-scale attacks could be detected by a few carefull users.
I wonder if SSL even enables that. For a start, do Netscape or Explorer
show the certified identity of a server when SSL is used, and how is one
supposed to know this display is genuine ?
Francois Grieu
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: Des S-Boxes
Date: Fri, 21 Apr 2000 19:23:32 +0900
schack01 wrote:
>
> Hello all!
>
> If i can modify the s-boxes in any way, is it possible to
> then "easaly" discover what key that are being used.
Yes.
See K.G. Paterson, ''Imprimitive Permutation Groups and Trapdoors in
Iterated Block Ciphers,'' FSE'99, LNCS 1636, 201--214, Springer-Verlag,
1999.
Hideo Shimizu
TAO, Japan
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Fri, 21 Apr 2000 11:18:39 GMT
Anthony Stephen Szopa wrote:
> You still don't know what you are talking about.
I am going on what I read in the ng.
> You are not drawing random digits / numbers from the bottle of
> numbered beans, you are drawing random number sequences of the
> numbers 1 - 14.
>
> You say you are in high school?
>
> Is it a high school for morons?
Why yes it is. I saw you graduated from here in 88'. Impressive.
> You apparently still have not read the Help Files and certainly
> not retained the most basic facts given in them, you think you know
> something yet consistently prove you know nothing.
Present your ideas in the ng, where you appear to be flaming everyone.
> Then you have the nerve to critique my Help Files as being
> inadequate, and you have the ridiculous audacity to tell me to
> make them more presentable and mature while you are a blithering
> knuckle head.
replace help file with technically correct paper. Present your ideas
properly. Have you ever even read a technical paper?
> You have never offered any factual support for even one of your
> positions. You can't even write a coherent paragraph. You might
> as well forget about going to a university.
7
It does require alot of memory.
> You are now in the permanent kill file.
Along with common sense I will jump in your kill file.
> You couldn't give any positive feed back if your life depended on it.
>
> Who in their right mind would waste anymore of their time with such
> a jerk?
Because I asked questions about your method and you don't respond.
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Fri, 21 Apr 2000 11:20:20 GMT
Anthony Stephen Szopa wrote:
>
> Tom St Denis wrote:
> >
> > Anthony Stephen Szopa wrote:
> > > Was it you who actually suggested that OAP-L3 may be as strong as
> > > the AES candidates? Someone in these news groups did very recently.
> > > I thought it was you.
> >
> > Um no it was not me.
> >
> > > What a let down: "For starters I am a stupid-ass when it comes to
> > > abstract algebra..."
> > >
> > > I guess your opinions carry little weight in this news group. I
> > > never gave them much weight any why simply because you never
> > > supported any of your positions. What did you expect?
> >
> > Actually I was being very realistic. I am a *high school* student, so
> > even if I wanted to, I don't know the required math todo it. *however*
> > as I stated, that doesn't mean others can't.
> >
> > If you took the mirrored sunglasses off you would notice I am actively
> > developping a crypto api, peekboo iii and working on odds and ends. And
> > obviously people reply so they think somewhat ok of my opinion.
> >
> > > This is all so richly comical.
> >
> > Because you are not taking anything serious.
> >
> > > Was it you who also suggested that the posters in this news group
> > > could help me work out "flaws" in OAP-L3?
> >
> > No I said "do your own homework".
> >
> > > So what makes you think I would want or accept your help or anyone
> > > else's help with OAP-L3? Nearly none of you really seems to
> > > understand the software anyway.
> >
> > Post the source code, then we'll talk. Or clean up your algorithm
> > description with some pseudo code... It's not the easiest description to
> > follow.
> >
> > > I want to assure you that I know what questions to ask regarding
> > > OAP-L3 and I have probably already asked them. I am completing
> > > Version 4.3 now.
> >
> > Do you have a copy for the 8051 yet?
> >
> > > I have also mapped out in detail Version 5.0, Version 5.1, and even
> > > a subsequent version. All more powerful and more secure and more
> > > versatile.
> >
> > How are they more secure?
> >
> > > Version 5.0 will be an evolutionary leap. Here is a table I
> > > included in a paper I wrote describing the fundamental concept
> > > of Version 5.0 and subsequent versions. I am posting it here
> > > (without any explanation) to put on record that I have already
> > > done it. For those interested in brain teasers, this could be an
> > > enjoyable one to figure out what is going on.
> > >
> > > When I release Version 4.3, then I will post this entire document
> > > describing the fundamentals of Version 5.0 (including this table)
> > > on my web site.
> > >
> > > Table 1 -
> > >
> > > Usg IIP MixFile1 MixFile2 MixFile3 Digit
> > > 5 8 6327491805 5382460791 1352094678 9
> > > 1 3 7246301598 6153704298 7801354926 3
> > > 6 5 7845069213 4019682573 2184065379 4
> > > 2 9 1904735268 4273860915 8670159423 7
> > > 4 1 0819374256 6421935087 9710324865 9
> > > 3 7 3145682790 8601534279 8523419670 4
> > > 1 2 1495638027 4139708562 8642375190 4
> > > 4 0 6712958403 9152743860 7618943205 5
> > > 6 4 1093865724 6491830725 2705941368 6
> > > 2 6 8610273495 3091268475 1846327095 8
> > > 5 8 7568421390 6729480531 0876925413 8
> > > 3 1 9310845672 0567483192 0835974162 9
> > >
> > > Usg = usage
> > > IIP = initial index pointer
> >
> > This makes no sense to me whatso ever.
> >
> > One very strong critic. How do you make the mixfiles to begin with?
> > Can your prng run on a 8051 with say 64 bytes ram? Stop calling it an
> > OTP. How are the newer versions any better?
> >
> > tom
>
> "This makes no sense to me whatso ever."
>
> What else is new?
>
> Don't worry about it.
>
> You are in my permanent kill file.
Notice how the smartarse did not respond to my question.
Tom
------------------------------
From: [EMAIL PROTECTED] (HCI SysAdmin)
Subject: Contract signing via cryptographic means
Date: 21 Apr 2000 11:13:20 GMT
Greetings, everybody.
I've been trying to do some research pertaining to using cryptographic
methods to simultaneously sign contracts. Schneier has a few paragraphs about
it (Applied Crypto, 2nd Ed., 5.7, pg. 118-122), but I definitely could use
more, updated data. Can anyone help?
Johnny
to reply: morpheus@math tau ac il (fill in the dots)
--
================================================
Carpe Diem, Quam Minimum Credula Postero Die...
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: password generator
Date: Fri, 21 Apr 2000 11:21:11 GMT
Joseph Ashwood wrote:
>
> Unfortunately, while I was gone strange thigns happened and
> my computer ended up powered down (with no output). I'll try
> again tomorrow.
> Joe
Hmm... windows whadda you expect :)
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Date: Fri, 21 Apr 2000 11:22:23 GMT
UBCHI2 wrote:
>
> He's probably right for the wrong reasons. Nothing but the one time pad has
> ever worked in cryptography for any length of time.
>
> Intractable math problem are only in the eye of the beholder. How many of you
> would have thought that the enigma could be broken?
This is amazingly false.
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Problems with OAP-L3
Date: Fri, 21 Apr 2000 11:25:11 GMT
Hey dude, address these 'issues'
1) What is the period
2) Why is it so damn big? [the state]
3) Why perms of 0-9? You waste alot of space that way, why not 0-16 or
0-255?
Why is it any better then say two fib sequences going thru Algorithm M?
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: New version of MIRACL
Date: Fri, 21 Apr 2000 11:25:52 GMT
Dann Corbit wrote:
>
> One of my favorite toys just got updated:
> http://indigo.ie/~mscott/
>
> Definitely worth a look.
> ;-)
Not to steal the fame, but I like MPI better, and by all means for the
others "try both :)".
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Sophie-Germain and ElGamal
Date: Fri, 21 Apr 2000 11:28:56 GMT
falissard wrote:
>
> For DH-ElGamal encryption, some people recommend
> using particular prime numbers (Sophie-Germain primes,
> where both p and (p-1)/2 are prime).
>
> See for example http://www.gnupg.org/rfc2440-12.html
>
> I am not sure PGP in its current version makes any use of
> Sophie-Germain primes.
> What could justify using them, from a cryptanalysis point of view?
>
> http://os390-mvs.hypermart.net
If the prime has known small sub-groups you can recover parts of the
key. Given for example
M^x mod p, where M belongs in a small sub-group, well you can now take
the discrete log (mod the order of the small group of course) and get
some clues as to what 'x' is. I.e you get 'x' in this form x' = x mod
g, where 'g' is the order of the small sub-group. If you get enough
small groups you could probably do something with the CRT to recover
'x'.
So using these types of primes (p-1/2 is prime too) is a good idea since
the *smallest* sub-group (other then 1 and -1) has p-1/2-1 elements,
this makes taking the discrete log more rewarding but *much* harder
todo.
Tom
------------------------------
From: elise <[EMAIL PROTECTED]>
Subject: nss
Date: Fri, 21 Apr 2000 13:30:17 +0200
I look forward to norton secret stuff decryption
please help me!
------------------------------
From: Sean Glazier <[EMAIL PROTECTED]>
Subject: Re: Newbie question
Date: Fri, 21 Apr 2000 07:53:55 -0400
my fat finger the mod number is actually 3337 sorry.
Thanks for the help
R124c4u2 wrote:
> >Sean Glazier
>
> >the first block encrypts as 688 raisedTo 17 mod 377 = 1570
>
> Any number mod 377 yields a maximum of 376, right? Are you keeping the
> quotient? If you are, throw it away.
------------------------------
From: Sean Glazier <[EMAIL PROTECTED]>
Subject: Re: Newbie question
Date: Fri, 21 Apr 2000 07:58:40 -0400
Son in the bottom of bruces book what you do is take
C = 1570 2756 2091 2276 2423 158
is actually 157027562091227624230158
when I get this on the other side I break it into to lengths the same size as
n and then
decrypt. That will work.
For my intial block size if n is x digits long my intial block size is n -1
digits long.
this will guarantee than the result is less than or = to n. If it is less pad
it with a 0 before combining and converting to ciphertext.
Correct.
THANKS SO MUCH!!
Doug Stell wrote:
> On Thu, 20 Apr 2000 18:46:27 -0400, Sean Glazier
> <[EMAIL PROTECTED]> wrote:
>
> >I am new to cryptograpy. I am attempting to write an ssl implementation
> >in smalltalk. So I got a bunch of books and starting reading til my head
> >hurt.
>
> Crypto will do that to your head - and more.
>
> >I am doing RSA Encryption algoritms.
> >I can do RSA encryption however my ciphertext does not come out to be
> >the
> >same size as the palintext.
>
> In RSA, each plaintext block must be numerically less than the
> modulus. Therefore, the plaintext block size is chosen to be slightly
> smaller than that of the modulus, e.g., round down to the next byte.
>
> The ciphertext block will also be numerically less than the modulus
> and probably the same size as the modulus.
>
> > I am assuming that this is a requirement. even in the
> >text Applied cryptography by Bruce Schneier second edition page 468.
> >
> >n = 3337
> >e = 79
> >d =1019
> >
> >he takes the plain text M = 688 232 687 966 668 3
> >
> >and he breaks it into digts of three for the block size.
> >
> >the first block encrypts as 688 raisedTo 17 mod 377 = 1570
> >
> >you do this to the rest of them and each of the opererations end in a 4
> >digit
> >number except for the last one.
> >
> >you combine them and what you have is a total number that is longer than
> >the
> >original.
>
> Correct. You have essentially padded each block out to the modulus
> size by adding insignificant leading zeros. In fact, Bruce shows it
> this way on the bottom of page 498
>
> >so lets say you coerced the asci plain text in the c pointer to some
> >long integer
> >resulting in M above when you coerce it back and then run the reverse
> >algorithm. the
> >string sizes are no longer the same. how do you know how to break up the
> >resulting
> >cipher text C = 1570 2756 2091 2276 2423 158 ?
>
> Again, you break it into modulus size blocks, which is how it was put
> together by the encryptor. I have inserted the spaces in the above
> line to show the blocking, as Bruce shows it on p468,
>
> >c is not the same size as m?!
> >
> >using the reverse logic with n four digits long I then would do the
> >reverse
> >operation chosing a block size of 3, I do the reverse operation on 157
> >and not 1570.
>
> You can't change the block size here, because it is determined by the
> modulus. As Bruce shows on page 468 that 1570^1019 mod 3337 = 688,
> which is correct.
>
> >the reverse operation on 157 yields the wrong answer of course. so my
> >question is how does this work. It seems to be a detail all these
> >documents and examples leave out. unless there are markers being
> >left around that allow yout to seprate the numbers again.
>
> The marker is the modulus, plus agreement on the part of both parties
> on how they shall do the blocking on some convienent boundary. Nothing
> needs to be inserted into the cyphertext as a block marker.
>
> Don't worry too much. Almost nobody would do a multiple-block RSA
> operation, because it is too slow.
------------------------------
** 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
******************************