Cryptography-Digest Digest #239, Volume #12 Mon, 17 Jul 00 17:13:01 EDT
Contents:
Re: RC4-- repetition length? (Guy Macon)
Re: DOS vs DOS (was Re: SECURITY CLEAN...) _long_ ([EMAIL PROTECTED])
Re: Carnivore and Man-in-the-middle ([EMAIL PROTECTED])
Info about non-repudiation as it relates to cryptographic mathematics
([EMAIL PROTECTED])
Re: DOS vs DOS (was Re: SECURITY CLEAN...) _long_ (Benjamin Goldberg)
MD2 (Daniel Leonard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: RC4-- repetition length?
Date: 16 Jul 2000 19:36:08 EDT
Rex Stewart wrote:
>
>
>In article <8kj04a$bd4$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> In article <[EMAIL PROTECTED]>,
>> John Myre <[EMAIL PROTECTED]> wrote:
>> > Bill Unruh wrote:
>> > <snip>
>> > >
><<cut>>
>>
>> I did some analysis a few years ago because RC4 resembled a
>> generator I had developed independently. Here's the analysis:
>>
>> http://burtleburtle.net/bob/rand/isaac.html
>>
><<cut>>
>>
>> - Bob Jenkins
>
>As I was looking at the above paper, I realised it said the
>method of keying prevented landing in a short cycle. I was
>wandering if the keying method in Ciphersabre 2 might be
>problematic since it uses the same keying method, but does
>not stop in the same place.
Source: http://ciphersaber.gurus.com/cryptanalysis.html
A Cryptanalysis of CipherSaber-1
CipherSaber 1 is a way of using Ron Rivest's RC4 cipher as a practical
symmetric key cryptosystem. It is intended to demonstrate that strong
cryptography can be very simple to implement, and therefor impossible
to suppress without massive infringement on civil liberties. A
CipherSaber-1 program can be written in 16 lines of QBasic. CipherSaber
is explained more fully at http://ciphersaber.gurus.com.
In CipherSaber-1, the ASCII representation of the user key or passphrase
is used directly as part of the RC4 key. To prevent the same RC4 key
from being used twice, a ten byte initialization vector (IV) is appended
to the user key to form the complete RC4 key. The IV is stored as the
first ten bytes of CipherSaber-1 encoded files.
This paper presents and analysis of several potential weaknesses in
CipherSaber-1 and recommendations for avoiding them. We use the same
notation here that Bruce Schneier uses in his description of RC4 in
the second edition of his Applied Cryptography, except that the stream
of cipher bytes that RC4 produces are denoted as C(i).
1. Key Size
In most cryptosystems, the longer the key, the better. However, it was
pointed out by several individuals who looked at CipherSaber-1 that a
very long user key could prevent the IV from affecting more than a few
of the S(i) values. This could cause leakage of plaintext. To insure
adequate mixing, we advised users to restrict their user key length to
54 characters or less, as most would anyway. This insures that the IV
will be mixed in at least four times during the setup process. Here
is a more detailed justification of the 54 character limit.
We want to estimate the likelihood that initial cipher bytes will be
unaffected by the IV. Assume a user key length of 54 bytes, the maximum
length we recommend. Then all the S(i) after the first 54 will be
affected by the IV during key setup. S(0) through S(53) will only be
affected by the IV if they are swapped in key setup rounds 55 through
256. That means there 202 opportunities. The probability that a given
S(i) will remain unswapped is
(255/256)**202 = 0.45.
So the expected number of the first 54 S(i) that are unaffected is
54*0.45 = 24.5. Thus the probability that S(i), where i is selected
at random from [0,256], has not been affected by the IV is
24.5/256 = 0.096
We can calculate the values that the first few S(i) are likely be have
after the key setup is complete if we assume that none of the first few
swaps hit an S(i) that has already been swapped previously. Recall that
at the start of key setup, S(i) = i, for all i.
Then:
S(0) = K(0)
S(1) = K(0)+K(1)+1
S(2) = K(0)+K(1)+K(2)+3
...
Call the successive cipher stream bytes C(i). If the first few S(i) are
not affected during the production of the first few cipher bytes, then:
C(0) = S(S(1) + S(S(1)))
C(1) = S(S(2) + S(S(1)+S(2)))
C(2) = S(S(3) + S(S(1)+S(2)+S(3)))
...
C(i) = S(S(i+1) + S(x)), where x = S(1)+S(2)+...+S(i+1) mod 256
Each S(i) for i between 0 and 53 have a 0.45 chance of being unaffected by
the IV. Therefore x has a 0.45**(i+1) chance of being unaffected.
The values S(x) and S(S(i+1)+S(x)) each have a .096 chance of being
unaffected. Therefore C(i) has a chance p(i) of being unaffected by the
IV, where
p(i) =0 .096*0.096*0.45**(i+1) = 0.0092*0.45**(i+1)
i 1/p(i)
0 242
1 539
2 1198
3 2662
1.1 C(0) Analysis
The most vulnerable Cipher byte would appear to be C(0). However assume
further that the first two characters of the user key are 7-bit ASCII
and donot contain control characters. Thus they are in the range [20, 7E]
hex, i.e. [32, 126] decimal.
Recall that S(1) = K(0)+K(1)+1 and therefore is in the range [65-253].
Also remember that: C(0) = S(S(1) + S(S(1)))
We see that the S(S(1)) term is guaranteed to select an S value that was
affected by the IV. So if the first two characters of the user key are
7-bit ASCII, C(0) will always be afffeced by the IV.
1.2 C(1) Analysis
Based on the above analysis, C(1) now appears to be the most vulnerable
cipher byte.
Remember that C(1) = S(S(2) + S(S(1)+S(2))) and S(1) = K(0)+K(1)+1
If K(0) and K(1) are in the range [27, 100] decimal, then S(1) must be
in the range [55, 201] decimal. This means that S(2) and S(1)+S(2) cannot
both be in the range [0, 53] and C(1) is guaranteed to be affected by
the IV. The condition that K(0) and K(1) are in the range [27, 100]
decimal, which is [1B, 64] hex, is satisfied if the first two characters
in the key are digits or uppercase characters. So if the first two
characters of the user key are digits or uppercase characters, C(1) will
always be afffeced by the IV. Given that the chance of C(1) being
unaffected by the IV is 1/539 which is less than the likelihood of any
random 8-bit value (1/256), we have not recommended that users restrict
the first two characters of their key to digits or uppercase.
1.3 Effect of Varying Key Size
For a 41 byte key (the size that insures 5 mixings), the C(1) unaffected
probability is computed as follows. The probability that one of the first
41 S(i) being unaffected by the IV is
(255/256)**(256-41)=.43
Probability of a random S(i) being unaffected is 0.43*41/256 = 0.069.
Probability p(1) of C(1) being unaffected is (0.43*0.069)**2 = 1/1134.
This is much less than the 1/256 likelihood of a random 8-bit value.
For a 74 byte key (the size that insures 3 mixings), the probability
p(1) that C(1) is unaffected by the IV is as follows.
The probability that one of the first 74 S(i) being unaffected by the
IV is:
(255/256)**(256-74) = 0.49
Probability of a random S(i) being unaffected is 0.49*74/256 = .141
Probability of C(1) being unaffected is (0.49*0.141)**2 = 1/209. This
is greater than the 1/256 likelihood of a random 8-bit value, justifying
our recommendation not to use a key this big.
2. Weak Keys
On September 22, 1995, Andrew Roos posted a paper to sci.crypt.research
that presented a class of weak keys in RC4. The conditions for this
class are
K(0) + K(1) = 0 mod 256.
These weak keys can leak information about the first byte of the key or
cipher stream.
Note that if the K(0) and K(1) are 7-bit ASCII characters at least one of
which is not NUL (00), the above condition is never satisfied. Thus the
use of printable 7-bit ASCII keys avoids this class of weak keys.
Several people have asked why the IV isn't prepended to the user key.
Doing so could permit weak keys to occur.
3. IV Size and Randomness
RC4 is a stream cipher. That means RC4 produces a stream of bits that are
xor'ed with the bits in the message. In a stream cipher it is essential
that the same key never be used twice.
If Sam the skilled snoop ever encounters two different messages encrypted
with the same RC4 key, then Sam can xor their cipher text to eliminate
the RC4 cipher bits because xor repeated twice is a null operation. Sam
will then have a stream of bits that represent the xor of the plaintext
of the two messages. If Sam knows the plaintext of one of the messages,
he can easily recover the other. Worse, if the messages are in a natural
language such as English, he can usually recover both messages -- even
if he knew neither. While revelation of encoded messages is bad news for
any cipher, in neither case is Sam able to recover the user key.
CipherSaber addresses the requirement that the same key never be used
twice by appending a ten byte quantity, called the initialization vector
(IV), to the users key. If the same IV is never used twice then the same
RC4 key can never be used twice.
The IV values can be any unique 8-bit quantities. For example, one could
use the year, month, day, hour minute second and hundredth of a second.
As long as no two messages were sent at exactly the same time, you would
be safe.
Another way to get a high likelihood of uniqueness is to use random values
for the IV bytes. This also makes encrypted file look like totally random
byte strings, which may be useful in some cases.
Since there are 80 bits in the IV, if n messages have been encoded with
the same user key, the probability q(n) that two messages will have the
same IV is
q(n) = n(n-1)/(2**80)
Even if one generated a billion messages, the probability that two
messages have the same IV is about one in a million. There is, however
a big "but" as we see in the next section.
3.1 Use of Built-in Random Number Generators to Create the IV.
The "but" is that we are assuming all the IV bytes are random. Creating
random values on a computer can be tricky, In particular, the built-in
random number generators supplied in most programming environments are
notoriously bad.
Most C programming environments offer a 32 bit random number generator.
If such a generator is used to create an 80-bit IV there is still at
most only 32 bits of randomness. The probability q(n) that two messages
will have the same IV is then
q(n) = n(n-1)/(2**32)
If you want q(n) to be less than one in a thousand, you can only send
about 2000 messages with the same user key. To achieve even this level
of safety, you need to initialize the random number generator with a
seed that has 32 bits of randomness.
3.2 Problems with QBasic as a Source of IV Randomness
A more extreme example is Microsoft's QBasic 4.5. This Basic interpreter
is shipped ont the CD-ROM that comes with every copy of Windows '95,
making it undoubtedly the most widely distributed programming environment
in the world. QBasic is very well suited for implementing RC4. It even has
a SWAP statement. However, its random number generator, RND, has only 24
bits of state. This means if you want q(n) to be less than one in a
hundred, you can only send about 400 messages with the same user key.
Even worse, the standard way to initialize QBasic's random number
generator is to put the statement RANDOMIZE TIMER at the beginning of
the program. TIMER is a built in function that returns a floating point
value containing the number of seconds since midnight. TIMER's resolution
appears to be 1/100 of a second. but the operating system only supports
resolution of 55 milliseconds. Assuming an eight hour variability in time
of encryption, TIMER only supplies about 19 bits of randomness. This
means if you want q(n) to be less than one in a hundred, you can only
send about 72 messages with the same user key.
3.3 Better Ways to Create the IV in QBasic
Here are some methods for generating the CipherSaber IV in QBasic.
The first is to xor the RND values with the characters returned by the
DATE$ function:
randomize timer
for i = 1 to 10
iv$(i)=chr$(asc(mid$(date$,i,1)) xor 256*rnd)
next i
This method sharply reduces the likelihood that two messages will have
the same IV. However, while the encrypted file will look random to a
casual observer, an expert could detect that the IV was not really random
and might even be able to extract the date of the message. In most cases
this is not a concern since the date could be determined by the message
header or file directory block.
Here is a method that comes closer to creating a truly random IV. It
captures key stroke times while the user key (k$) is entered.
get: c$=inkey$
if c$ = "" then goto get
if c$ = CR$ then go to done
i=i+1
j=(i mod 10) + 1
k$(i)=c$
randomize timer
iv$(j)=chr$((256*rnd + asc(iv$(j)) mod 256)
goto get
Even with DOS's low timing resolution, one can expect an 8 tick variation
per character entered, producing 3 bits of entropy. With a 15 character
user key, this would produce about 45 bits of entropy. The 18 to 20 bits
of entropy represented by the first randomize timer call would bring the
IV close to 65 bits of entropy. Given that users tend to enter random
keys slowly, 4 bit of entropy per character is more likely, bringing us
close to a full 80 bits of randomness.
One disadvantage of the key stroke timing method is that you must force
the user to enter their key afresh for every message.
4. CipherSaber-2
To solve the problems caused by the single round of key setup in RC4,
I was originally going to include a CipherSaber-2 in my proposal.
CipherSaber-2 has a parameter N that specifies the number of times the
RC4 key setup loop is repeated. For N=1, CipherSaber-2 would just be the
same as CipherSaber-1. The value of N could be agreed upon by both users
and kept secret along with the key. Indeed, N can be considered part of
the key. I see three advantages over RC4:
1. For n >= 2 it solves the mixing problem. User keys can be up to 246
bytes without any problems.
2. It would coax users to have longer keys. A big weakness in
cypto-for-the-masses is that people just will not pick long enough keys.
Having a second "bucket" helps from a human factors perspective (sort of
like area code and 7-digit phone number vs. a straight 10-digit phone
number)
3. Large values of N makes exhaustive key search much slower.
A thousand-fold increase in the time needed to test a key is equivalent
to adding 10 bits of entropy to the key. A CipherSaber-2 written in C
and running on a Pentium could probably stand a five or six digit N
without an unacceptable delay.
[Note: It has been pointed out to me that an attacker can easily try
successive values of N, so the actual benefit of keeping N secret
is minimal. It might be better for each user to determine the largest
value of N that is tollerable on their computer and to agree to use the
smaller of the two acceptable N values when communicating with another
CipherSaber user. agr 9/16/98]
I did not include CipherSaber-2 in the initial announcement because I
wanted to keep the proposal simple and because I wanted to use a cipher
that was straight out of a textbook. Also it is foolhardy to introduce
a new cipher without a time for other people to review it.
5. Recommendations
To use CipherSaber securely, we recommend that users:
Use a high entropy key or passphrase. Using low entropy keys is the most
common mistake users make A low entropy key will render any cryptosystem
vulnerable. We recommend using a key consisting of 15 or more random
characters, or 5 more short dictionary words.
See http://www.hayom.com/diceware.html for a simple yet rigorous way to
make high entropy passphrases.
Keep keys 54 characters or shorter (most users would do this anyway)
Use 7-bit printable characters, at least for the first few characters
(most users would do this anyway as well)
Use a strong method for generating the random IV, particularly if you
plan to encode more than a few dozen messages with the same user key.
See Section 3.3, above.
For highest security, use CipherSaber-2, along with a strong source of
random numbers.
====================================================================
I want to thank Hal Finney for his valuable comments on a much
earlier draft. Additional comments on this paper in general and on
CipherSaber-2 in particular are welcome.
Arnold G. Reinhold
March 19, 1998 Rev f. HTML version, Basic and PC timer correction and
minor edits April 22, 1998, May 13, 1998. CipherSaber-2 correction
Sept. 16, 1998
Source: http://ciphersaber.gurus.com/cryptanalysis.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DOS vs DOS (was Re: SECURITY CLEAN...) _long_
Crossposted-To: alt.privacy
Date: Mon, 17 Jul 2000 20:26:20 GMT
[Way off-topic, bail out now! :]
In sci.crypt Rick Braddam <[EMAIL PROTECTED]> wrote:
> Well, if Linux was every bit as capable as Win98, then I wouldn't have had
> any problems writing CDs with my CD-RW drive after installing Red Hat 6.0
> on my machine. I guess I didn't really have a problem... all I had to do
> was shut down Linux and use LILO to reboot under Win98, then double-click
> on the Easy CD Creator icon. Then I could write CDs all day long. Why did
> I have to do that? No Linux program or driver was available for my CD-RW
> drive, from anywhere. Why didn't I write my own driver or program to run
> my CD-RW drive? Why should I, I already had a commercial quality program
> that could "get things done", just one of tens of thousands of
> applications which run on the PC platform under Windows.
Just for the record, Windows doesn't support EIDE CD-RWs either. The
ASPI layer is an Adaptec product, and requires that you own either an
adaptec host adaptor or software product to upgrade it. It's not
uncommon for drives to not work under various Windows versions, if the
user doesn't own Easy CD Creator.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Carnivore and Man-in-the-middle
Date: Mon, 17 Jul 2000 20:31:52 GMT
[EMAIL PROTECTED] wrote:
> As most of you already know, the FBI has announced its intention to
> install the "Carnivore" packet-sniffing system in every ISP's data path,
> such that all traffic passing through that ISP can be sniffed by some
> Carnivore system. The stated purpose of this system is to snoop on the
> contents of suspected criminals' emails when permitted by judicial
> wiretap order.
As I understand it, they intend to place it at particular ISPs when
they have a court order to intercept mail.
> Reading about it made me think about the "Man in the Middle" attack
> against public key cryptosystems. In order for "Man in the Middle" to
> work, the adversary must be able to intercept any communication between
> any two users of the cryptosystem and replace that communication with
> their own selected data.
Subsituting packets would be feasible (I wouldn't say trivial), but
defeating the underlying encryption schemes would be impractical.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Info about non-repudiation as it relates to cryptographic mathematics
Date: Mon, 17 Jul 2000 20:43:25 GMT
Hello,
I am looking for a detailed reference that describe information about
non-repudiation as it relates to cryptographic mathematics.
Any reference, paper, URL is greatly appreciated.
Thanks,
Gary
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: DOS vs DOS (was Re: SECURITY CLEAN...) _long_
Date: Mon, 17 Jul 2000 20:54:05 GMT
Rick Braddam wrote:
>
> "Chem-R-Us" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Fafnir wrote:
> > >
> > > Yeah, but some of us need an os that can actually get things done.
> >
> > Obviously you know little about operating systems.
>
> That's not obvious from what Fafnir said. Do you get a lot of exercise
> by jumping to conclusions like that?
>
> > Linux workstations are every bit as capable as any other
> > workstation, more so than a gatesware toy-station!
>
> At first I thought you were talking about hardware here, since you
> said workstations. Then I remembered that many Linux workstations are
> the exact same hardware that "gatesware" (Win95 & Win98) runs on. So
> you must be talking about software. Linux and Win98?
>
> Well, if Linux was every bit as capable as Win98, then I wouldn't have
> had any problems writing CDs with my CD-RW drive after installing Red
> Hat 6.0 on my machine. I guess I didn't really have a problem... all I
> had to do was shut down Linux and use LILO to reboot under Win98, then
> double-click on the Easy CD Creator icon. Then I could write CDs all
> day long. Why did I have to do that? No Linux program or driver was
> available for my CD-RW drive, from anywhere. Why didn't I write my own
> driver or program to run my CD-RW drive? Why should I, I already had a
> commercial quality program that could "get things done", just one of
> tens of thousands of applications which run on the PC platform under
> Windows.
So because there exists one type of CD-RW drive for which a Win9x driver
exists and for which *you* can't find a Linux driver for, this makes
linux not able to get things done? What an interesting conclusion.
> My subject line? I really get a kick out of how *nix and Linux fans
> compare their operating systems to Win9x. They just don't seem to have
> a clue. Win9x may extend and add functionality to the underlying
> operating system, but they are _not_ the operating system. If they
> were, there wouldn't be a "boot to DOS" option, and you couldn't boot
> a Win9x system up to just before the point where Windows loads and
> stop there with a command interpreter running. Good old command.com.
> Running under DOS 7.0.
> They did change the version string for Win98 so that DOS identifies
> itself as Windows 98, but it's still DOS running command.com. And
> Windows is a Graphical User Interface _application_ which uses DOS
> services.
>
> The *nixes and Linux are just DOSes running csh or bash or whatever
> other command shell you like. In spite of their insistance on
> redefining a "real" OS as requiring it to be multi-user, an OS is just
> a program which operates and controls hardware devices that are
> attached to or part of the computer system, and providing services to
> applications so the applications can use those devices. Multi-user is
> a _type_ of OS, not a requirement for an OS to be a "real" OS, just
> like Tape Operating System (TOS) and Disk Operating System (DOS) are
> types of OSes.
I don't think that an OS *has* to be multi-user, but it *does* have to
do true multiprogramming - something that DOS only emulates. Also, it
*does* have to have a way to prevent a user in normal running mode from
changing, and perhaps damaging, parts of the system [In linux, this is
logging in as superuser vs logging in as a regular user; what equivilant
is there in Win9x?]. If you say this is unimportant, consider that if
you somehow get a virus on your computer. If you are in user mode, it
can only trash *some* files, but if you are in root mode, it can trash
*everything*.
Also, I believe that for things like web servers [which might download
programs] or programs you've downloaded for fun, there needs to be a way
to run it in some sort of sandbox. In unix/linux, a way of [at least
partially] doing this is to make up a user id for it [especially good
for servers], or use chroot. DOS of course doesn't have user ids. Does
it have anything like chroot? Or anything similar for restricting a
program's access?
> So if the *nix and Linux command-line fanatics want to compare OSes,
> they would be more fair and honest if they compared to MS-DOS 7. Then
So we should have an analogy, unix is to dos, as x11 is to win9x?
Oops, forget I asked that - Any program I can run when X11 is going can
still be run with just my OS and a shell, simply by setting the display
environment variable to something appropriate. If it runs under Win9x,
it won't run under DOS. If it runs under DOS, then to run it under
Win9x, we need to pop up an emulator. Mebbe I'm wrong, but there seems
to be a bit of a problem comparing unix/linux with dos.
> I'd have to agree that theirs is superior. They still won't run
> Win98's GUI natively, though, so they are useless to me. Their GUIs
> also won't run Win98 applications natively, so they are still useless
> to me, and millions of other computer system users.
Howcome there are implementations of X for Win9x, but none of Win9x for
Unix? If Win were *so* much better and more important, there would be,
wouldn't there?
If Win9x is 'just a program' which runs under DOS, then shouldn't it be
easy to make some existing DOS emulators run the Win9x program? This
hasn't been done...
> Technical superiority doesn't cut it by itself. In my opinion, OS/2
> Warp is still technically superior to Win98 (and NT/2K ??), but how
> many _new_ software titles for it do you see at your local computer
> store? Without the software, it can't "actually get things done". If
> someone would write 30 or 40 thousand device drivers for it, and port
> 40 or 50 major apps to it, it would probably take the market away from
> Windows. But it ain't gonna happen.
>
> My Linux 6.0 installation? I deleted all the files, deleted the
> partitions, then added VFat32 partitions for Win98. I had booted the
> system up under Linux 10 or 15 times without any problems (over a
> period of several days). Then I brought the system up and started
> Gnome, browsed around some, then shut down, several times -- again
> with no problems. I decided to have Gnome autostart. After all, I
> wanted a windowing system, not a command line system. The fifth or
> sixth time I brought the system up with Gnome autostarting, it came up
> with a multi-colored confetti display.
Umm, why did you delete the files, partitions, etc?
> No indication why, just did it. I shut the system off, rebooted, and
> got the same thing again.
Perhaps I'm mistaken, but can't you press Control+Alt+F1 to switch from
Gnome to text-mode?
> I went digging into the book that came with the CD and figured out how
> to boot the system up to a command prompt and logged in as root. I
> spent hours looking through man files, info files, and configuration
> files for anything which might help correct the problem, and never
> found anything that worked. I didn't (and don't) have time for that,
> so I removed Linux. Maybe someday I'll try it again, but I doubt it.
Ok, I'll admit this does sound like a problem. What were you told when
you called technical support and asked for help?
> I'll stick with my gatesware toy-station for the time being. It does
> everything I want it to and a whole lot more. Bloated software? So
> what. I've got a 12.7 Gig drive in my machine now, and Gateway is
> advertising:
>
> 11. Seagate� 15.3GB BarracudaT Hard Drive
> $102.95 after $20 instant rebate (reg. price $122.95)
>
> that I could add right in without any hassles.
>
> Sorry this is so long, and I don't mean to rant. If I've written
> anything which can be considered derogatory to Linux or Linux users, I
> apologize for it now. Such is not my intention. I agree that Linux is
> an excellent OS with features (that Windows don't have) that are
> absolutely essential in some situations. I don't agree that every user
> of a computer requires those features at this time. Apparently even
> Gates & Co. agrees that those features will be required in the future,
> since they've stated that Win98 will not be developed further and
> Win2K is the next Windows. Based on NT instead of DOS 7, Win2K should
> be much harder to hack than Win98 is.
>
> This is a lot for my $.02 worth (and maybe overpriced at that).
>
> Rick
--
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
This is the signature worm.
Help me spread by appending me to your signature.
------------------------------
From: Daniel Leonard <[EMAIL PROTECTED]>
Subject: MD2
Date: Mon, 17 Jul 2000 21:06:02 GMT
Does anyone have any papers or links related to the MD2 message digest
algorithms.
I know about RFC 1319, so do not send this link. I am looking for critics
and attacks.
==========
Daniel L=E9onard
OGMP Informatics Division E-Mail: [EMAIL PROTECTED]
D=E9partement de Biochimie Tel :
Universit=E9 de Montr=E9al Fax :
Montr=E9al, Quebec Office: Pavillon Principal G-312
Canada H3C 3J7 WWW :
------------------------------
** 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
******************************
