Cryptography-Digest Digest #295, Volume #12 Thu, 27 Jul 00 04:13:01 EDT
Contents:
Selecting cipher - which one to use? ("Lisa Retief")
Re: Proving continued possession of a file ([EMAIL PROTECTED])
Re: Cursory Comments on Recursion (Mok-Kong Shen)
Re: Selecting cipher - which one to use? (Runu Knips)
Re: Database encryption (Runu Knips)
On granularity of encryption operations (Mok-Kong Shen)
Re: 8 bit block ciphers (Mack)
Re: Question Regarding Encrypting CD-ROM -RW Disks (Greg)
Re: 8 bit block ciphers (Mack)
Re: Selecting cipher - which one to use? (Mok-Kong Shen)
Re: CD destruction (Greg)
Re: CD destruction (Greg)
Re: CD destruction (Greg)
A new book about Enigma (Mok-Kong Shen)
Re: R: CD destruction (Greg)
Re: Selecting cipher - which one to use? (Mack)
Re: It has been documented / disclosed in the past that ... (jungle)
Re: What is DES3mCBCMACi64pPKCS5? (Mack)
Re: How to Convert p12 Files to Ascii for certificate installation
([EMAIL PROTECTED])
Re: FWZ1 (Anonymous)
Re: Question Regarding Encrypting CD-ROM -RW Disks (jungle)
Re: CD destruction (jungle)
Re: MD5 algorithm questions (Mack)
Re: MD5 algorithm questions (jungle)
Re: Selecting cipher - which one to use? (Mack)
Re: How is the security of Outlook Express encryption ? (Sébastien SAUVAGE)
----------------------------------------------------------------------------
From: "Lisa Retief" <[EMAIL PROTECTED]>
Subject: Selecting cipher - which one to use?
Date: Thu, 27 Jul 2000 08:02:44 +0200
Hi all,
I am a crypto ignoramus and need to select a cipher to use in a software
development project. The requirements are as follows - we will need to
encrypt a large amount of data as a whole (as securely as possible), but
when decrypting we will only be decrypting small chunks of the larger data
at a time - ie. we will not have access to the rest at the time. Someone has
suggested IDEA but I can't find any documentation on this cipher?
Is there some resource which compares ciphers and aids in the decision I
need to make?
Regards,
Lisa Retief
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Proving continued possession of a file
Date: Thu, 27 Jul 2000 05:59:03 GMT
In article <[EMAIL PROTECTED]>,
Andru Luvisi <[EMAIL PROTECTED]> wrote:
> Here's an idea:
>
> Define Gen(n,b,i) = b + n*i Pick primes p and q. Let n = p*q.
>
> When alice gets the file, she breaks it up into blocks of some size,
> and numbers them x_1 through x_m.
>
> She computes: summary = (x_1^Gen(1, b, i)) * (x_2^Gen(2, b, i)) * ...
mod n
>
> She saves p, q, n, b, i, and summary in quick-access memory (hard
> drive?) and puts the file away on a tape.
>
> When she wishes to confirm that Bob still has the file, she generates
> a random value, r. She sends Bob:
> b*r mod (p-1)*(q-1)
> i*r mod (p-1)*(q-1)
> n
>
> Bob computes, and sends to Alice:
> (x_1^Gen(1, b*r, i*r)) * (x_2^Gen(2, b*r, i*r)) * ... mod n
>
> Alice raises this result to r^-1 mod (p-1)*(q-1) and verifies that it
> matches the saved summary value.
>
> Will this work?
I don't think it will. Bob can just store the two numbers:
k_1 = x_1 * x_2 * x3 * ... mod n
k_2 = ((x_1)^1) * ((x_2)^2) * ((x_3)^3) * ... mod n
Then, when Alice gives him b*r and i*r, he returns:
((k_1)^(b*r)) * ((k_2)^(i*r)) mod n
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Cursory Comments on Recursion
Date: Thu, 27 Jul 2000 08:25:35 +0200
wtshaw wrote:
> Base Translation deals with two or more bases, but the current topic deals
> with one at a time. In the trials, seeds, or primers, are sensed as
> recurring in a string.
>
> I received a few days ago a back issue of Cryptologia, July, 1989. I
> found that the author presented much of the same data that I had derived.
> He and I agree on some of the same speculations, and perhaps conjured the
> same error regarding binaries, which the current effort seems to
> redefine. Crux offeres his assistance.
Sorry that I understand too little of what you stated. If there is only
one base, then, given a number represented in that base, what
operations are you doing to do on the coefficients (recurrently)?
The term 'seeds' reminds me of pseudo-random number generators.
But I guess you are probably not doing that at all. Could you
explain with a tiny example or else symbolically? I believe other
readers may have the same difficulties to understand the issue.
Thanks.
M. K. Shen
------------------------------
Date: Thu, 27 Jul 2000 08:32:02 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Selecting cipher - which one to use?
Lisa Retief wrote:
>
> Hi all,
>
> I am a crypto ignoramus and need to select a cipher to use in a software
> development project. The requirements are as follows - we will need to
> encrypt a large amount of data as a whole (as securely as possible), but
> when decrypting we will only be decrypting small chunks of the larger data
> at a time - ie. we will not have access to the rest at the time. Someone has
> suggested IDEA but I can't find any documentation on this cipher?
>
> Is there some resource which compares ciphers and aids in the decision I
> need to make?
(a) Don't use IDEA. It uses only 64-bit blocks, uses multiplications and
even
worse it is PATENTED and you'll have to pay (much !) money for using
it.
(b) Any cipher can satisfy the need to decrypt data at any point, it
just
depends upon how you have used it. For example, to decrypt data
stored
in CBC mode, you just need the last block before the one to decrypt
all following data.
(CBC mode is when you put a unique IV before every message, and xor
each plaintext with the previous block before encrypting).
(c) I would recomment using Twofish. It is free, uses 128 bit blocks,
can
handle up to 256 bits of key data, it is very fast and very secure.
Serpent is maybe even more secure than Twofish (arround factor 1.5),
but
also substantly slower (>2 times).
Blowfish isn't bad also, but it uses only 64 bit blocks, is very
hard to
implement in hardware (if you would need that someday), needs very
much
memory for the key schedule (~4KB) and shouldn't be used to encrypt
more
than 2**(64/2) * blocksize == 32 GB of data with the same key
(birthday
attacks), in fact you better use far less.
------------------------------
Date: Thu, 27 Jul 2000 08:34:54 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Database encryption
Paul Rubin wrote:
> So in general, one should not use cryptography software to secure
> highly sensitive data. It's simply too easy for keys to escape by
> accident or on purpose. If the software crashes and leaves a core
> dump, the keys may be in it. If the computer gets a virus, that might
> scan memory and find the keys. And so on. Sensitive data should be
> secured by hardware.
But if you can steal the disc, you can steal the hardware with the
keys, too ? I don't understand the advantage here.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: On granularity of encryption operations
Date: Thu, 27 Jul 2000 09:14:08 +0200
In the old days, the unit of encryption was generally the
character, which corresponds roughly to the byte of our time.
Bits as processing units started with the Vernam cipher. All
modern ciphers deal meticulously at the bit level.
I suppose, however, that, notwithstanding the efficacy of
fine granularity operations provided by the modern ciphers,
there could be some essential value in additionally
considering certain rather simple operations on larger units.
One such operation that suggests itself is a pseudo-random
permutation of the computer words of the message file.
I should appreciate to learn other ideas and opinions on the
issue.
M. K. Shen
=========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: 8 bit block ciphers
Date: 27 Jul 2000 07:07:28 GMT
>In article <[EMAIL PROTECTED]>,
>Mack <[EMAIL PROTECTED]> wrote:
>>Does anyone have any information on 8 bit block
>>ciphers? I don't mean simply shuffling an array.
>>And I am aware that it is simple to do a dictionary
>>attack. I am looking for methods that can be used
>>instead of array shuffling.
>
>If you mean a block cipher suitable for implementation on 8-bit
>microcomputers, Skipjack is probably the best choice. For 4 bits,
>try GOST. DES is also doable. Skipjack uses the least RAM (about 3
>bytes plus the key).
>
>See http://www.brouhaha.com/~eric/crypto for PIC microcontroller
>implementations of DES and Skipjack.
>
>
Now that is something I never considered.
Thanks a million... well at least 80 bits worth ;)
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Question Regarding Encrypting CD-ROM -RW Disks
Date: Thu, 27 Jul 2000 07:04:03 GMT
> > I am making is that with my notebook, and others like it
> > I am sure, if you had to destroy the HD in a hurry, you could simply
> > slide it out and go at it with a sledge hammer.
>
> hammer is not destroying data but ONLY DRIVE ...
> you need to understand the difference ...
I do know the difference. Are you implying that a shattered drive
can be reconstructed? SHIT!
--
Craig: Well what will you do?
William: I will invade England and defeat the English on their own
ground.
Craig: Invade? That's impossible.
William: Why? Why is that impossible? You're so concerned with
squabbling for the scraps from Longshank's table that
you've missed your God-given right to something better.
There is a difference between us.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: 8 bit block ciphers
Date: 27 Jul 2000 07:10:27 GMT
>Scott Fluhrer <[EMAIL PROTECTED]> wrote:
>> One thought is looking at a design like NewDES (by Robert Scott, it's in
>> Schneier).
>
>I'd personally wouldn't favor NewDES. It was designed quite a while ago,
>before many of the advances in differential and linear cryptanalysis, so
>there was no way for the author to benefit from that. And, my understanding
>is that it has not received much scrutiny from the research community.
>
>Have you looked at Skipjack? It seems remarkably well-suited for low-RAM
>environments. There are also GOST and Treyfer, which both seem quite good
>for low-RAM environments, and don't require 256 bytes of ROM for their S-box.
>(Make sure to get the updated version of Treyfer, which adds a round counter
>to prevent slide attacks.) All of these have received some analysis in the
>open community, certainly not as much as DES or the AES candidates and not
>as much as I'd like, but at least they seem to be holding up ok so far.
>
>
I have not seen treyfer do you have a reference.
I am looking into skipjack.
Thanks
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Selecting cipher - which one to use?
Date: Thu, 27 Jul 2000 09:20:48 +0200
Runu Knips wrote:
> (a) Don't use IDEA. It uses only 64-bit blocks, uses multiplications and
> even
> worse it is PATENTED and you'll have to pay (much !) money for using
> it.
I understand what you said except 'multiplications'. What's inherently
wrong with using multiplications? Thanks.
M. K. Shen
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: CD destruction
Date: Thu, 27 Jul 2000 07:11:38 GMT
> Think of a text file with 20% of the letters missing.
Ya, like instead of trying to find a 128 bit key, you are left
trying to find 20% of the cipher text AND the 128 bit key. Of
a total of 5G bits, we are talking 1G bits of cipher text and
the 128 bit key.
I honestly think such an undertaking is too much even for the NSA.
If anyone disagrees, please, by all means. I would like to know
why I am wrong...
--
Craig: Well what will you do?
William: I will invade England and defeat the English on their own
ground.
Craig: Invade? That's impossible.
William: Why? Why is that impossible? You're so concerned with
squabbling for the scraps from Longshank's table that
you've missed your God-given right to something better.
There is a difference between us.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: CD destruction
Date: Thu, 27 Jul 2000 07:14:03 GMT
In article <[EMAIL PROTECTED]>,
Dave Hazelwood <[EMAIL PROTECTED]> wrote:
> What material are CD's made out of ? Polycyanate?
>
> Whatever it is there must be a solvent for it.
>
> MEK? TCE? Gasoline?
>
> Get the solvent and dissolve the CD!
Somehow, the way you said that made me think of the alphabet
soop that had letters floating to the top spelling out words... :)
--
Craig: Well what will you do?
William: I will invade England and defeat the English on their own
ground.
Craig: Invade? That's impossible.
William: Why? Why is that impossible? You're so concerned with
squabbling for the scraps from Longshank's table that
you've missed your God-given right to something better.
There is a difference between us.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: CD destruction
Date: Thu, 27 Jul 2000 07:08:33 GMT
> Further, the pieces are big enough to read data
> from with a microscope.
ya, all 5G+ bits...
--
Craig: Well what will you do?
William: I will invade England and defeat the English on their own
ground.
Craig: Invade? That's impossible.
William: Why? Why is that impossible? You're so concerned with
squabbling for the scraps from Longshank's table that
you've missed your God-given right to something better.
There is a difference between us.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: A new book about Enigma
Date: Thu, 27 Jul 2000 09:33:21 +0200
I have just seen the following book that may be of interest
to those who like to read histories of crypto:
H. Sebag-Montefiore, Enigma. Weidenfeld & Nicolson,
2000.
M. K. Shen
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: R: CD destruction
Date: Thu, 27 Jul 2000 07:18:14 GMT
> This may well be an unsound idea, but the last time I had to
> destroy a CD-R I just nuked it in the microwave.
Well, if you don't have a solvent, a fire place lit already, or
a power tool, I guess a microwave would make a decent improvision
for when the ninja clad swat team is jumping through your door.
Toilets just won't cut it for CDs...
Microwaves are really cheap and abundant these days. But I would
recommend a Microwave sitting next to your PC on an uninterruptable
power supply - in case the swat team cut the power to your house
before making entry.
Just a thought...
--
Craig: Well what will you do?
William: I will invade England and defeat the English on their own
ground.
Craig: Invade? That's impossible.
William: Why? Why is that impossible? You're so concerned with
squabbling for the scraps from Longshank's table that
you've missed your God-given right to something better.
There is a difference between us.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Selecting cipher - which one to use?
Date: 27 Jul 2000 07:31:28 GMT
>Hi all,
>
>I am a crypto ignoramus and need to select a cipher to use in a software
>development project. The requirements are as follows - we will need to
>encrypt a large amount of data as a whole (as securely as possible), but
>when decrypting we will only be decrypting small chunks of the larger data
>at a time - ie. we will not have access to the rest at the time. Someone has
>suggested IDEA but I can't find any documentation on this cipher?
>
>Is there some resource which compares ciphers and aids in the decision I
>need to make?
>
>Regards,
>Lisa Retief
>
I would stay away from IDEA. It is patented. 3-DES is used for most electronic
commerce at the current time. Blowfish and Twofish are pretty good.
Square and Rjindael are also pretty good. Blowfish and 3-DES are
64 bit. Twofish, Square and Rjindael are 128 bit. Serpent is fairly slow
so it probably isn't suitable from your description. Rjindael is newer than
Square but uses a similar structure.
RC-5 and RC-6 are also patented. RC-5 is parameterized which
makes it a good choice if you want to shell out cash. It is more popular
than IDEA.
If you really don't know a lot about crypto then you probably need to
learn a bit about protocols. Most failures of crypto systems are in
the implementation rather than the cipher itself.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: It has been documented / disclosed in the past that ...
Date: Thu, 27 Jul 2000 03:36:18 -0400
any info / help in Ramzi Yousef WTC bomber case ?
[EMAIL PROTECTED] wrote:
>
> jungle <[EMAIL PROTECTED]> wrote:
> > it has been documented / disclosed in the past that :
> > ======================================================
>
> > - K Mitnick case - his encrypted files has not been cracked
> > - Ramzi Yousef WTC bomber - it took FBI experts more than a year to decipher 2
> > files
>
> > QUESTION : what has been used as encryption [software, algorithm, method] ?
>
> In Mitnick's case, word of mouth would seem to indicate multiple
> iterations of DES. He allegadly had confidence in the algorithm
> [Littman, The Fugitive Game pp98-99]. Given the time frame involved,
> I'm not sure there were many ready-made programs offering much
> superior protection.
>
> On a related note, there isn't really any incentive to decrypt his
> files. The government already had an overwhelming case against
> him. Alot of them are most likely trash as well. His friend encrypted
> a pile of garbage multiple times prior to being raided. [Littman pp
> 54-55]
>
> --
> Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: What is DES3mCBCMACi64pPKCS5?
Date: 27 Jul 2000 07:36:41 GMT
>I'm using a cryptography module that supports an encryption mode
>called Mech_DES3mCBCMACi64pPKCS5. You give it a plaintext buffer and
>it pads it to a multiple of 8 bytes using PKCS5, encrypts it in 3DES
>CBC mode and adds a MAC. I understand about 3des/CBC and PKCS5 but
>am not sure of how the MAC is supposed to be computed, and I'm trying
>to code an interoperable implementation.
>
>Does anyone know if there's a standard way to do this? I don't think
>the PKCS standards say anything about it.
>
>Thanks.
>
>
It seems to be saying that it uses a 64 bit MAC.
This seems logical for DES3. I think there
is a standard from NIST covering the use of
DES as a MAC you might want to check it out.
I don't have a reference but I think it is online.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to Convert p12 Files to Ascii for certificate installation
Date: Thu, 27 Jul 2000 07:27:35 GMT
> Simplest way is with the openssl pkcs12 and x509 commands (see
> the built in help strings). www.openssl.org.
>
Well, thanks but i have no unix available nor a compiler to compile the
source for win...any other ways ?
btw: How is the name of this data structure , i mean
BEGIN CERTIFICATE
... etc
END CERTIFICATE
thanks
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Thu, 27 Jul 2000 01:43:14 -0600
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: FWZ1
Here's another simple challenge for any who are interested in
reverse
engineering. I started but don't have the time. To help pique
your
interest I'll mention that this company's sales droids
constantly talk
about how the Intelligence Community (their caps, not mine) is
Very
Interested in their software and the NSA Review Report is due
out at
any time.
This company named Infraworks (www.infraworks.com) makes some
rather
outrageous claims about their document-protection system, called
InTether. Here's a small sample:
InTether(TM) protects the content of files, like mp3, video,
software or documents, allowing the sender of information to
control how the recipient uses it, including control over
printing, copying and forwarding. If you don't want it
forwarded,
InTetherTM gives you that control. If hacking is attempted,
the
file self-destructs. Just like in Mission Impossible. No
other
technology can do this.
Yes, their home page actually says Mission Impossible and they
actually expect people to take them seriously.
>From the user's point of view, what InTether does is this
(simplified,
there are some options I won't mention):
The InTether packager takes a user-specified file, allows the
user to
select what permissions they'd like recipients to have, and
produces
an executable file as an output, which can then be sent to the
recipient(s).
The recipients execute this file. If they have the InTether
reciever
installed, they are asked where they'd like to put the extracted
file.
The software extracts the file and invalidates the package. The
user
can then double-click the extracted file and the contents cannot
be
printed, copied to the clipboard, e-mailed, etc., and the file
can
only be opened the number of times specified by the creator of
the
package, after which it disappears.
One part of this is actually some fairly clever engineering.
They
apparently get into the windows file system drivers at a low
enough
level that it seems to be impossible to open the file without
invoking
their control software. And their software somehow prevents
printing
and copying, regardless of the type of the file. And, if you
try to
bypass the windows filesystem by, say, booting Linux, what you
see is
a zero-size file. I haven't used a disk editor to see if I could
actually locate the data.
I actually consider this to be a potentially useful piece of
software.
It does a pretty good job of controlling distribution of
electronic
documents as long as the recipient isn't *really* interested in
defeating the controls.
However, their claims are extravagant because it's clear that
(a) all
of the data are in the package file, along with the decryption
key (or
else the same key is used for all package files) and (b) the
data are
on the disk in some location, even if well-hidden. Further,
their
sales reps are at least as arrogant about the security of their
technology as
I started the task of reverse-engineering what they're doing but
then
some real work got in the way. What I discovered in my brief
analysis
was:
The document file in the InTether package is located at offset
0xd000,
and it is encrypted with some reasonably good block cipher with
64-bit
blocks, used in ECB mode. I say it's reasonably good because the
output looks uniform and very small changes in input make large
changes in the corresponding block. I was hoping that it would
be a
stupid cipher that I could analyze with some simple chosen-
plaintext
attacks. The same key is used to encipher every document,
because if
I package the same data multiple times I get the same output
every
time.
My next steps would be to throw it in a debugger and see what I
can
learn about it and/or to try to find the key in the files.
If anyone feels like giving it a shot, I'll gladly give you a
round of
applause.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: Question Regarding Encrypting CD-ROM -RW Disks
Date: Thu, 27 Jul 2000 03:46:37 -0400
Greg wrote:
>
> > > I am making is that with my notebook, and others like it
> > > I am sure, if you had to destroy the HD in a hurry, you could simply
> > > slide it out and go at it with a sledge hammer.
> >
> > hammer is not destroying data but ONLY DRIVE ...
> > you need to understand the difference ...
>
> I do know the difference. Are you implying that a shattered drive
> can be reconstructed? SHIT!
the difficulty level of recovering data from H/D that has been
"go at it with a sledge hammer."
are astonishing lower than difficulty of recovering data WIPED with wiping
software ...
the answer to your question, yes ...
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: CD destruction
Date: Thu, 27 Jul 2000 03:50:24 -0400
Greg wrote:
>
> In article <[EMAIL PROTECTED]>,
> Dave Hazelwood <[EMAIL PROTECTED]> wrote:
> > What material are CD's made out of ? Polycyanate?
> > Whatever it is there must be a solvent for it.
> > MEK? TCE? Gasoline?
> > Get the solvent and dissolve the CD!
>
> Somehow, the way you said that made me think of the alphabet
> soop that had letters floating to the top spelling out words... :)
beautiful analogy ...
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: MD5 algorithm questions
Date: 27 Jul 2000 07:51:09 GMT
>Hello,
>
>First of all, note that I crossposted so you might want to prune the
>reply headers if you reply to this. I have a few questions regarding the
>MD5 algorithm that I haven't been able to find answers for.
>
>Are all unique messages which are SHORTER than the MD5 code length (128
>bits) guaranteed to have different MD5 hashes? In other words, does
>there exist a 64-bit message that has the SAME MD5 hash as a different
>64-bit message? Or is there only a possibility of hash collisions for
>messages that exceed 128 bits in length? I realize that the probability,
>if it exists, is very small.
>
>Also, if I want to fold the 128-bit hash into 64-bits, is it sufficient
>to exclusive-or the top 64 bits with the bottom 64 bits? Please note
>that I'm NOT using this for any security purposes, and therefore any
>security arguments against doing this do not apply; I'm only using MD5
>in order to get a good hash code of some data.
>
>Sorry to post to security groups about something not relating to
>security, but I was unsure where else to go to ask questions about MD5.
>
>Thanks,
>Scott
>
If it isn't going to be used for security consider a CRC
It is faster and you can change the selection until you
get one that doesn't interact badly with the data.
For a 64 bit CRC.
For 64 bit messages with a one prepended
you are guaranteed not to have collisions. If you
include all smaller messages this should be reduced to
63 bits.
With a given data set with formated data you can
usually determine if the data will interact with the
CRC. Ie. with ASCII text you are pretty safe
unless the messages are a lot longer than
the CRC. Or they are a special form like
BASE-64 encoding.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: jungle <[EMAIL PROTECTED]>
Subject: Re: MD5 algorithm questions
Date: Thu, 27 Jul 2000 03:56:10 -0400
Mack wrote:
=============
>
> If it isn't going to be used for security consider a CRC
than why to verify in first place ?
use MD5 or / and SHA-1 ...
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Selecting cipher - which one to use?
Date: 27 Jul 2000 07:57:10 GMT
>
>
>Runu Knips wrote:
>
>> (a) Don't use IDEA. It uses only 64-bit blocks, uses multiplications and
>> even
>> worse it is PATENTED and you'll have to pay (much !) money for using
>> it.
>
>I understand what you said except 'multiplications'. What's inherently
>wrong with using multiplications? Thanks.
>
>M. K. Shen
>
>
Nothing that I know of except maybe speed. Not all processors
handle multiply well. And most handle multiply mod 65537
even worse. Of course there are some pretty fast implementations.
Best suggestion is use an algorithm that isn't patented.
Why buy the goat when you can get cow milk for free ;)
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
Subject: Re: How is the security of Outlook Express encryption ?
From: [EMAIL PROTECTED] (Sébastien SAUVAGE)
Date: Thu, 27 Jul 2000 08:09:38 GMT
[EMAIL PROTECTED] (Mack) wrote in
<[EMAIL PROTECTED]>:
>>jungle wrote:
>>>
>>>
>>>Greg wrote:
>>>>
>>>> > Does anyone know what is the key lenght of Outlook Express's
>>>> > singing/encryption ?
>>>
>>>===============
>>>
>>>> I developed a piece of software that placed itself between
>>>> OE and the crypto layer and intercepted the plain text.
>>>
>>>this has nothing to do with the ORIGINAL question ...
>>
>>Does anyone know how good the case hardening on this lock is?
>>I am using it to lock my cardboard shoebox shut and I am worried
>>about someone with a diamond blade hacksaw cutting the lock off.
>>
>>
>I have a good lock on the vault my computer is in but
>I know my ISP can scan all of my message.
>Now can he read the encrypted ones?
The protocols used for email (SMTP and POP3) are NOT encrypted.
Thus your ISP can read all your emails.
Outlook downloads these messages in clear, and then encrypts them
before writing them to disk.
If you want to encrypt your message so that your ISP cannot read them,
you will have to use PGP (using private/public key cryptosystem.)
PGP 6.5.1i is free. http://www.pgpi.org.
--
Sébastien SAUVAGE - [EMAIL PROTECTED]
http://www.bigfoot.com/~sebsauvage
------------------------------
** 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
******************************
