Cryptography-Digest Digest #65, Volume #14 Tue, 3 Apr 01 01:13:00 EDT
Contents:
Re: Public Domain MARS Implementation Source Code ("Roger Schlafly")
Re: Idea - (LONG) (Nicol So)
Re: Data dependent arcfour via sbox feedback ("Bryan Olson")
Re: Data dependent arcfour via sbox feedback ("Bryan Olson")
Re: Data dependent arcfour via sbox feedback ("Bryan Olson")
Re: AES VS. DES ("Douglas A. Gwyn")
Re: keys and random (Brian D Jonas)
FTP Server - AES C++ Implementation + Sourcecode ("James Wyatt")
Re: keys and random ("Tom St Denis")
FTP UP ("James Wyatt")
Re: Data dependent arcfour via sbox feedback (Terry Ritter)
Re: Data dependent arcfour via sbox feedback (Terry Ritter)
Re: Avoiding bogus encryption products: Snake Oil FAQ (Ichinin)
Re: Data dependent arcfour via sbox feedback (Ichinin)
simple libdes question ("Sean Kelly")
Re: simple libdes question ("Douglas A. Gwyn")
PK Algorithm Idea ("Tom St Denis")
Re: simple libdes question (Jim Gillogly)
rational PK? ("Tom St Denis")
Re: simple libdes question (Paul Rubin)
----------------------------------------------------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Public Domain MARS Implementation Source Code
Date: Tue, 03 Apr 2001 00:42:24 GMT
"Eric Lee Green" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Mon, 02 Apr 2001 22:12:31 GMT, Nathan J. Yoder <[EMAIL PROTECTED]>
wrote:
> > This may sound like a trivial/stupid question, but I am looking for
an
> >implementation of MARS that has been released in the public domain. I
have
> Note that MARS may be covered by several IBM patents. You may wish to
> contact an intellectual law expert prior to using MARS in any design.
IBM has granted royalty-free license to use its Mars patents to implement
Mars, regardless of whether or not it won the AES contest. (Mars didn't win,
but you are free to use it anyway.)
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Mon, 02 Apr 2001 21:12:09 -0400
Reply-To: see.signature
Mok-Kong Shen wrote:
>
> Nicol So wrote:
>
> > It's actually quite simple. Consider a source that outputs a sequence of
> > 8-bit characters of even parity. Now a message of N characters consists
> > of N*8 bits, but the amount of entropy needed to transmit the message
> > with perfect secrecy is only N*7 bits. You don't need to expend 8 bits
> > of shared randomness to perfectly mask a plaintext symbol--you can use
> > an random even-parity character with only 7 bits of randomness.
> >
> > The point is: source characteristics affect the amount of key entropy
> > required for perfect secrecy.
>
> ... But how about the case where he
> doesn't have that knowledge? Does it help anything in
> security? Thanks.
If you don't know the exact amount of entropy in the plaintext, and
still want to have perfect secrecy, you may be able to use a safe
overestimate, depending on how much partial knowledge you have. In some
cases, that may mean assuming the source to be potentially of maximum
entropy, as a practical necessity. However, practical necessity is not
what this (sub)thread is about.
In a previous message, you wrote:
> If one has r bits of truly random bits (never mind how to
> get this), one can *only* encrypt r bits with perfect
> security in the sense of Shannon.
[emphasis added]
And Douglas Gwyn, apparently sensing a misappreciation of Shannon's
result, responded and wrote:
> Well, no, it depends on the source characteristics.
Judging from your follow-ups, you didn't seem to get the point of the
comment.
What I've been doing was trying to clarify the point Douglas Gwyn made,
and not trying to address issues with practical application of OTP.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: Data dependent arcfour via sbox feedback
Date: Tue, 03 Apr 2001 02:35:31 GMT
Ken Savage wrote:
>Bryan Olson wrote:
>
>> I'm not sure it's been stated, so I'll note an obvious
>> defect in the proposed scheme: If we grant the attacker
>> multiple known plaintexts from the same starting state, he
>> can easily discover the state.
>
>Forgive the list of questions...
>
>1) By 'state', are you referring to the sbox/x/y/c values,
>or are you referring to the random stream's contents which
>are xor'ed with the plaintext?
The sbox/x/y/c values.
>In the first case, you would
>be able to continuously predict the PRNG, but the latter
>would be squashed by the length of the longest plaintext.
Right.
>2) How would this be any different from standard RC4?
With RC4 getting the sequence is automatic from one known
plaintext (up to the length of the plaintext as you pointed
out), but no amount of chosen plaintext tells us more about
the state. With this modification, using different bytes
induces different c values, which probe around in the s-box.
>3) If there was an "IV" prepended to the known plaintext,
>the combination thereof encrypted, would you be able to
>determine the state. All of the plaintext is known, but
>that dang 16-byte header isn't :)
I'll assume the IV's can't be chosen by the attacker, and
are not sent in the clear.
For a given key, after encrypting a 16-byte IV there are
still only 256 different states. I'd suggest choosing
plaintexts that always begin with the same character, so the
encryption of that character will reveal which instances are
in the same state. Varying the subsequent characters lets
us poke around in the state.
--Bryan
------------------------------
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: Data dependent arcfour via sbox feedback
Date: Tue, 03 Apr 2001 02:36:04 GMT
Terry Ritter wrote:
>
> Benjamin Goldberg wrote:
>>The difference between the proposal and the patent is the number of
>>input streams, one versus two.
>
>But then the question arises as to whether or not there is in fact
>just a single input stream. That does not appear to be the case.
>
>Here is one way it might go:
>
>
>>Here's the proposed modified RC4:
>>
>>byte x, y, z, sbox[256];
>>encipher(byte data) {
>> x = (x + 1) & 255;
>
>Here x might be the "first data source."
>
>
>> y = (y + sbox[x]) & 255;
>
>Here y might be the "second data source," and sbox[] might be the
>"substitution means for translating values from said first data source
>into said result data or substitute value."
>
>The "second data source" is modified by said "result data" before use,
>but no part of the claims excludes that possibility.
The word "source" excludes the possibility. The sequence of
y values is in fact a _product_ of the substitution process,
not a source. If unclear of the interpretation of "source",
just read the background and look at the diagrams in the
patent.
The quotes above also assume an incremented variable is a
valid "source". If that's true, doesn't the following
algorithm fulfill the description from claim 1? How about
claims 2, 7 and 8?
Assume a (pseudo) random data source S
initialize T[0..k-1] to hold 0..k-1
for i in 0..k-2
j = S.next() scaled/shifted to be in i..k-1
output T[j]
swap(T[i], T[j])
--Bryan
------------------------------
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: Data dependent arcfour via sbox feedback
Date: Tue, 03 Apr 2001 02:37:04 GMT
Bryan Olson wrote:
>
>>Terry Ritter wrote:
>>>
>>>Bryan Olson wrote:
>>>
>>>>In article <[EMAIL PROTECTED]>, Terry Ritter wrote:
>>>>>[...]
>>>>>However, the Dynamic Substitution claims do not require encryption by
>>>>>substitution.
>>>>
>>>>All the claims on encryption methods require two data
>>>>sources, the first of which is transformed by substitution
>>>>to form the output or substitute values.
>>>
>>>OK, that's it. I can't make you read; or having read, understand; or
>>>having understood, accurately represent the facts.
>>
>>And yet I have.
>
>I can't say whether you have read it or not. But I can certainly say
>whether you have understood, which you have not.
>
>
>>[...]
And in the [...] you edit out where I was right and you
had no clue. Spare us the act, I understood just fine.
>>>So the claim that: "RC4 and the proposed modification do not encrypt
>>>by substitution of the data characters; that's what makes Ritter's
>>>patent inapplicable," is laughably ridiculous and clearly false to
>>>anyone willing to actually read and understand the patent. We can be
>>>sure that a court would be so willing.
>>
>>You also have to read and understand RC4 and the proposed
>>modification.
>
>Absolutely not; that is completely wrong.
>
>Each patent claim is interpreted on its own
The question, once again, is whether the patent applies to
these schemes. You need to understand both the patent and
these schemes to determine that.
> -- perhaps by using the
>body text of that patent to interpret particular words or phrases --
>but definitely independent of any other patent or development.
Yes, and what constitutes a data source and result data is
clear from the discussion and diagrams in the patent. RC4
and the new proposed scheme use XOR as the combiner, not
dynamic substitution.
>Interpreting a design for infringement with respect to any patent
>basically involves matching the words and phrases of the claim to the
>design. If all of some claim does match, infringement is indicated.
Yup.
--Bryan
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: AES VS. DES
Date: Tue, 03 Apr 2001 02:45:26 GMT
Volker Hetzer wrote:
> There are methods better than exhaustive key search.
Actually, no, not under normal circumstances.
------------------------------
From: Brian D Jonas <[EMAIL PROTECTED]>
Subject: Re: keys and random
Date: Mon, 2 Apr 2001 22:50:34 -0400
I imagine you are getting tired of this diffie hellman key stuff, but I
keep getting mixed answers. This is the last post on this topic..
a=2^x mod p
p is a sophie germain RANDOM prime, which is what is recommended
EVERYWHERE on the net for diffie hellman key exchanges.
Side note: to be a sophie germain prime q, then q=2p+1 where p is a
smaller prime... Not the reverse...
It will NOT be hardcoded.... 2 will be hardcoded.
I obviously agree now that hardcoding the prime would be a long term
security
hazzard.
Is the 2 hardcoded a problem ?
x is any random number less than p
Then a and p are sent to another user.
That user uses that p, and there own random x1 to make a1. Their a1 is
sent back... They can compute k using p,a and x1...
k=a1^x mod p
k=a^x1 mod p
k=k
This checks out as far as k=k when I run my code.. Just want to make sure
this is the proper 100% method, that is is a-ok to hardcode 2 and that (a)
and (p) are public numbers.
Thanx a ton
------------------------------
From: "James Wyatt" <[EMAIL PROTECTED]>
Subject: FTP Server - AES C++ Implementation + Sourcecode
Date: Tue, 03 Apr 2001 03:10:03 GMT
FTP Server: wyattearp.dns2go.com 2001
login/password: crypt/crypt
...jim
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: keys and random
Date: Tue, 03 Apr 2001 03:17:38 GMT
"Brian D Jonas" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> I imagine you are getting tired of this diffie hellman key stuff, but I
> keep getting mixed answers. This is the last post on this topic..
>
> a=2^x mod p
>
> p is a sophie germain RANDOM prime, which is what is recommended
> EVERYWHERE on the net for diffie hellman key exchanges.
> Side note: to be a sophie germain prime q, then q=2p+1 where p is a
> smaller prime... Not the reverse...
> It will NOT be hardcoded.... 2 will be hardcoded.
> I obviously agree now that hardcoding the prime would be a long term
> security
> hazzard.
No this is all wrong. First off p must not be random, only unique, and even
that's not required if the sub-group of Z*p is big enough to prevent the
precomputation step of the I.C or NFS orwhatever attack.
> Is the 2 hardcoded a problem ?
Well you can use 2 or whatever is a good generator (in this case anything
but -1, 0 or 1).
> x is any random number less than p
Any number less than p-1, remember that the exponents are taken modulo p-1.
> Then a and p are sent to another user.
> That user uses that p, and there own random x1 to make a1. Their a1 is
> sent back... They can compute k using p,a and x1...
> k=a1^x mod p
> k=a^x1 mod p
> k=k
This looks right.
> This checks out as far as k=k when I run my code.. Just want to make sure
> this is the proper 100% method, that is is a-ok to hardcode 2 and that (a)
> and (p) are public numbers.
Well as "good coding" goes you should be able to use any base, but
specifically setting it to 2 is not bad. In my current library I am
writting I have hard coded generators and primes. But you can use any pair
in the remainder of the code.
Tom
------------------------------
From: "James Wyatt" <[EMAIL PROTECTED]>
Subject: FTP UP
Date: Tue, 03 Apr 2001 03:58:03 GMT
ftp: wyattearp.dns2go.com 2001
login: crypt
password: crypt
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Data dependent arcfour via sbox feedback
Date: Tue, 03 Apr 2001 04:03:49 GMT
On Tue, 03 Apr 2001 02:36:04 GMT, in <oGay6.318$iy4.90@interramp>, in
sci.crypt "nospam"@"nonsuch.org" ("Bryan Olson") wrote:
>Terry Ritter wrote:
>>
>> Benjamin Goldberg wrote:
>>>The difference between the proposal and the patent is the number of
>>>input streams, one versus two.
>>
>>But then the question arises as to whether or not there is in fact
>>just a single input stream. That does not appear to be the case.
>>
>>Here is one way it might go:
>>
>>
>>>Here's the proposed modified RC4:
>>>
>>>byte x, y, z, sbox[256];
>>>encipher(byte data) {
>>> x = (x + 1) & 255;
>>
>>Here x might be the "first data source."
>>
>>
>>> y = (y + sbox[x]) & 255;
>>
>>Here y might be the "second data source," and sbox[] might be the
>>"substitution means for translating values from said first data source
>>into said result data or substitute value."
>>
>>The "second data source" is modified by said "result data" before use,
>>but no part of the claims excludes that possibility.
>
>The word "source" excludes the possibility. The sequence of
>y values is in fact a _product_ of the substitution process,
>not a source. If unclear of the interpretation of "source",
>just read the background and look at the diagrams in the
>patent.
Any sequence of data values is "a source." We can see this throughout
the patent, including: "A first data source and a second data source
are combined into a complex intermediate form or result. . . ." Note
the lack of description about the "ultimate" origin of any data
sequence treated as a "source."
Also note that the body description and diagrams represent one example
of implementation, and do not limit the claims. This is patent law,
but to make it clearer, it is explicitly stated at the end of the body
text: "While my above descriptions contain many specificities, these
should not be construed as limitations to the scope of the invention,
but rather as an exemplification of a preferred embodiment thereof.
Many other variations are possible. Accordingly, the scope of the
invention should be determined not by the embodiments illustrated, but
by the appended claims and their legal equivalents."
And then we have the testimony from the claim itself:
"
1(b) change means, at least responsive to some aspect of said second
data source . . .
"
Note the phrase "some aspect of," clearly indicating that the second
data source may be modified before being used in the "change means."
But, if you don't like the word "source," perhaps you would prefer the
word "value":
"
15. A two-input one-output logic mechanism or design, which combines a
first input value with a second input value, including:
(a) substitution means, potentially including a plurality of
storage means, for saving substitute values and translating said first
input value into an output value, and
(b) change means, at least responsive to some aspect of said
second input value, for re-defining a proper subset of the substitute
values within said storage means, potentially after every substitution
operation.
"
>The quotes above also assume an incremented variable is a
>valid "source".
Of course.
>If that's true, doesn't the following
>algorithm fulfill the description from claim 1? How about
>claims 2, 7 and 8?
>
>
> Assume a (pseudo) random data source S
>
> initialize T[0..k-1] to hold 0..k-1
> for i in 0..k-2
> j = S.next() scaled/shifted to be in i..k-1
> output T[j]
> swap(T[i], T[j])
>
I'm not happy with any mechanism claimed to be Dynamic Substitution
being inherently limited to a sequence of a particular length. It is
implied throughout the patent body that there is no such limitation.
Thus, I expect that the Dynamic Substitution patent distinguishes from
the described mechanism. I think you can probably use it without
patent implications.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Data dependent arcfour via sbox feedback
Date: Tue, 03 Apr 2001 04:05:02 GMT
On Tue, 03 Apr 2001 02:37:04 GMT, in <kHay6.319$iy4.90@interramp>, in
sci.crypt "nospam"@"nonsuch.org" ("Bryan Olson") wrote:
>Bryan Olson wrote:
>[...]
>Yes, and what constitutes a data source and result data is
>clear from the discussion and diagrams in the patent.
But the "exemplification of a preferred embodiment" does not limit the
scope of the claims.
>RC4
>and the new proposed scheme use XOR as the combiner, not
>dynamic substitution.
First, I am not discussing RC4.
Next, from the Dynamic Substitution patent, the 6th paragraph under
the Objects and Advantages section:
"Another object of this invention is to provide a mechanism or process
by which two confusion sources can be combined to produce a
more-complex confusion result which may be used by some other combiner
mechanism."
It's hard to see how that could be spelled out any clearer, and
similarly hard to see how anyone who actually read the patent could
have missed it. And yet we know you have.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Avoiding bogus encryption products: Snake Oil FAQ
Date: Fri, 23 Mar 2001 07:05:55 +0100
Henrick Hellström wrote:
> This doesn't make sense. If the attacker knows the method of key
> initialization, the hash function will normally not add any entropy
> whatsoever, but only (a) increase the effort of a brute force attack on the
> password by a linear factor since each guess has to be hashed, and (b)
> possibly be necessary to make the key fit a legal key size. It is also
> possible that the key set up scheme of the cipher makes it extremely
> vulnerable to differential analysis, meaning that it is easier to extract
> the key from known plain text than to guess and hash passwords.
Some ciphers become weak because of their crappy key setup routines, and
as
such they need to have passwords hashed to have any kind of strenght.
Simple demonstration:
1) Encrypt some data (using RC4) with the key "hubba"
2) Encrypt some data (using RC4) with the key "hubbahubba"
3) Compare outputs.
Mvh
Ichinin
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Data dependent arcfour via sbox feedback
Date: Fri, 23 Mar 2001 07:16:04 +0100
Mok-Kong Shen wrote:
> Could someone explain why DES is NOT covered by
> that claim?
> Thanks.
Errrm... Prior art?
------------------------------
From: "Sean Kelly" <[EMAIL PROTECTED]>
Subject: simple libdes question
Date: Mon, 2 Apr 2001 21:23:11 -0700
First, I apologize for the slightly off-topic nature of this post. But I'm
not getting any responses from a similar question in comp.security.unix and
this seemed like the next most likely newsgroup.
Is there a common convention for handling/detecting the (0-8) garbage
characters at the end of a DES encrypted file? Since every DES-encrypted
file has a filesize that's a multiple of 8 bytes, it's likely that some
portion of the last 8-byte block, when decrypted, will be garbage tacked on
to the end of the original file by the encryption scheme (I'm using cbc).
Currently, I'm zeroing out everything past a newline ('\n') detected in the
final decrypted 8-byte block but this seems a dubious method at best (works
okay for text files, not for binary). I imagine there has to be a standard
way of handing this but I haven't been able to find source or reference to
give me pointers. Any suggestions?
Sean
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: simple libdes question
Date: Tue, 03 Apr 2001 04:31:51 GMT
Sean Kelly wrote:
> Currently, I'm zeroing out everything past a newline ('\n') detected
> in the final decrypted 8-byte block but this seems a dubious method
> at best (works okay for text files, not for binary).
Since every possible bit pattern might be found in a binary file,
you can't figure out whether trailing garbage is garbage or not
just by looking at it outside any context. In many cases, the
way the binary file is used will simply ignore extra bits. In
other cases, the first, say, 32 bits transmitted can be a file
length (including those 32 bits or not, choose one) and that will
tell you where the genuine data ends.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: PK Algorithm Idea
Date: Tue, 03 Apr 2001 04:39:27 GMT
Has anyone considered a hybrid DH-RSA system?
You pick two sophie germaine primes P and Q, Then you pick G a generator
for Z*P and Z*Q (and in turn of Z*PQ ???), you then make a private exponent
which is 1 < x < lcm(P-1,Q-1). Your public key is then the triplet (G, G^x
mod PQ, PQ).
It then can be used in ElGamal modes (with the appropriate modifications) I
think... (don't have applied crypto at home... hmm)
The idea is that you can't compute the discrete log until you know the
primes (is that true?). And since the primes are unique you have to solve
the dlog in two different groups name Z*P and Z*Q (is that true either?).
Please comment. Most likely this won't work, but it's just an idea.
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: simple libdes question
Date: Mon, 02 Apr 2001 21:46:43 -0700
"Douglas A. Gwyn" wrote:
>
> Sean Kelly wrote:
> > Currently, I'm zeroing out everything past a newline ('\n') detected
> > in the final decrypted 8-byte block but this seems a dubious method
> > at best (works okay for text files, not for binary).
>
> Since every possible bit pattern might be found in a binary file,
> you can't figure out whether trailing garbage is garbage or not
> just by looking at it outside any context. In many cases, the
> way the binary file is used will simply ignore extra bits. In
> other cases, the first, say, 32 bits transmitted can be a file
> length (including those 32 bits or not, choose one) and that will
> tell you where the genuine data ends.
This turned out to be a real issue in Stage 9 of Simon Singh's
challenge. It was a DES encryption, and after the ASCII plaintext
were 8 bytes of garbage. I looked at them off and on for six
or eight months, trying them every which way for a crib to Stage
10, since I didn't see any other reason to have 8 binary bytes
there. Only after the Brute Squad solved Stage 9 did one of them
point out that libdes produces this extra block, and we assumed
that this is where it came from.
--
Jim Gillogly
Hevensday, 12 Astron S.R. 2001, 04:43
12.19.8.1.17, 11 Caban 20 Cumku, First Lord of Night
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: rational PK?
Date: Tue, 03 Apr 2001 04:48:40 GMT
Hmm well I can't get to sleep... here's another wacky idea :-)
Why not use the set of rationals (i.e a/b where a and b are int Z and b !=
0) in say DH? Basically you pick g = a/b and perform DH like normal but all
your numbers are in a/b (except the exponent). And before you reduce modulo
the prime you reduce the fraction by dividing out the GCD of a and b. I.e
((3/5)^4) mod 7/7 would be (9/25 mod 7/7)^2 mod 7/7 = (2/4 mod 7/7)^2 = 4/16
mod 7/7 = 1/4 mod 7/7 = 1/4
The idea is that you mess up the normal sense of "arithmetic" (as *I* know
it, and what I know couldn't fill a thimble so be kind in replies) by
removing common factors. Normally you would think (3/5)^4 mod 7/7 = 81/625
mod 7/7 = 4/2
When I say mod 7/7 I mean take the numerator mod 7 and denom mod 7 .. i.e
a/b mod 7/7 = (a mod 7) / (b mod 7).
Any thoughts?
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: simple libdes question
Date: 02 Apr 2001 21:49:44 -0700
"Sean Kelly" <[EMAIL PROTECTED]> writes:
> Is there a common convention for handling/detecting the (0-8) garbage
> characters at the end of a DES encrypted file?
Yes, using PKCS5 padding when encrypting the file is not the most
efficient thing in the world but it's a common convention. Basically
on encryption, you pad the plaintext with 1 to 8 bytes, so you get a
multiple of 8 characters to encrypt. The pad bytes all have value N,
where N is the number of pad bytes. Examples:
1. Plaintext = 20 bytes, pad bytes = 4. So you pad with four 0x04 bytes.
2. Plaintext = 16 bytes, pad bytes = 8 (since you must have >0 pad bytes).
So you pad with eight 0x08 bytes.
To un-pad after decryption, just look at the last byte of the
decrypted ciphertext. That tells you how many pad bytes to remove.
------------------------------
** 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
******************************
