Cryptography-Digest Digest #291, Volume #12 Wed, 26 Jul 00 15:13:01 EDT
Contents:
Re: Get Free Software (Mark Wooding)
Re: Playing with an 8 bit cipher. (Mack)
Re: 8 bit block ciphers (Mack)
Re: Proving continued possession of a file (Andru Luvisi)
Re: Question.How to avoid weak curves? (Mike Rosing)
Re: Small hash checksum (Mack)
Re: Get Free Software (George Peters)
Re: How is the security of Outlook Express encryption ? (Mack)
looking for s-box generator ("ET")
Re: How is the security of Outlook Express encryption ? ("???")
Re: Get Free Software (Tom Anderson)
Re: Cryptographic Camouflage ("Joseph Ashwood")
Re: Get Free Software ("Joseph Ashwood")
Re: looking for s-box generator (Runu Knips)
Re: AESC-stream cipher (Tom Anderson)
Re: AESC-stream cipher (Tom Anderson)
MD5 algorithm questions (Scott Long)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Get Free Software
Date: 26 Jul 2000 16:37:32 GMT
George Peters <[EMAIL PROTECTED]> wrote:
> At www.endecs.com/uenigma.exe an entire suite of encryption products
> is available. Because of specilized setup, it is a self-extracting
> .exe which you will need to run the setup.exe after extraction.
Oh. This is the sort of `free' software which isn't really free at
all. No source code, no right to modify the software...
The web page http://www.endecs.com/ is a scary place. It's another of
these bizarre `secure mail exchange' things.
: This service will provide you and other people signed up for the
: service the ability to send email and attachments securely.
That's a good idea. So good, in fact, that Phil Zimmerman had it years
ago.
: The chief benefit from using the service is you don't have to worry or
: deal with anyone's personal key.
Oh, dear. Alarm bells are ringing by this point.
: It will work like this:
:
: * You sign up (no setup fees!) for the service. We will create a
: profile for you and send your personal key and software to you
: (similiar to our Eureka Email product). There will only be a $5
: fee a month for personal and $15 a month for corporate accounts.
Wow! They give me my own key, to save me from choosing a bad one! This
must be secure.
No, hang on. How do they send me my key, and make sure that nobody can
read it on the way? I'd recommend using PGP-encrypted email, but that
rather begs the question of why I'd want to prat about with this EnDecs
thing. (GnuPG, which is PGP-compatible is proper Free Software.)
: * You encrypt a message and/or attachments using our software
: (perferrably addressing it to another registered client) and your
: messages will be sent to us for processing.
:
: * We receive the email and using your personal key on file, decrypt
: the message and/or attachments and if the recipient is also signed
: up for the service, we'll encrypt it again using the other
: person's personal key. We'll then send it along for delivery.
: The person you are sending data to does not have to be registered
: with the service if no encypted data is being sent.
Ummm... But then they get to read all of my mail. I have to trust them
not only to write secure software and put proper encryption in it (which
I don't), but also to handle all of my mail which is too sensitive for
me to send unencrypted. For as long as I use the service.
Of course, I could use GPG on my messages before sending them to EnDecs,
but this rather defeats the point.
: * When you receive an encrypted message, you then use your personal
: key to decrypt the data.
:
: Nothing could be easier! Even if you are sending to multiple people,
: each will arrive encrypted with their own personal key. No shared
: keys, no key management, no hassles!
No security!
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Playing with an 8 bit cipher.
Date: 26 Jul 2000 16:40:35 GMT
"Trevor L. Jackson, III" [EMAIL PROTECTED] wrote
>
>Do you have a definition of "reasonably fast"? What is your desired data
>rate?
>Can you tolerate variations in the data rate?
I don't know what the limits are going to be in practice. Since only
relatively
small amounts of data are to be transfered the data rate can be fairly low.
The maximum amount of data would be between 64 and 128 bytes.
Each transaction should complete in about 1/10 of a second so the
mechanism you describe might prove useful.
>
>The backtracking mechanism mentioned above would require on average 512
>operations
>(the original description is wrong), but has a worst case performance of 32K
>operations (the frequency of this condition is 1:256!). If you have a low
>power
>machine at 10 MHz your average throughput would be about 2 Kb/sec.
>
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: 8 bit block ciphers
Date: 26 Jul 2000 16:48:13 GMT
>From: "Scott Fluhrer" [EMAIL PROTECTED]
>
>Obviously, you've never worked in an embedded environment. We're talking
>about a CPU on a chip that might be used to control a toaster. Yes, it can
>get that constrained.
>
>One thought is looking at a design like NewDES (by Robert Scott, it's in
>Schneier). As designed, it could be done with no additional RAM space other
>than the key and the data block (and the chaining block if you are using it
>in CBC). It does have a fixed 256 byte sbox, but that's ROM, and on the
>embedded controllers I worked with (long, long ago), that wouldn't be too
>much of a problem.
>
>I have heard that the initial sbox proposed was weak, and that an
>alternative was much better against differential attacks. However, I do not
>have a reference to that. There is a Robert Scott that posts here on
>occasion, maybe you can ask him.
>
>--
>poncho
>
Thanks for the input. I will have to look that up.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: Proving continued possession of a file
Date: 26 Jul 2000 09:31:01 -0700
Andru Luvisi <[EMAIL PROTECTED]> writes:
[snip]
> Could this be fixed by encrypting the file first and computing the
> summary information using the encrypted file? Alice stores the key
> she used, and sends Bob the key along with the other information in
> the challenge, although it never changes.
Actually, it just occured to me... encryption might not be needed...
What if you just added a counter to the blocks before exponentiating?
Andru
--
Andru Luvisi, Programmer/Analyst
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Question.How to avoid weak curves?
Date: Wed, 26 Jul 2000 11:45:07 -0500
Robert Harley wrote:
> One thing that needs to be done is counting points on the curves.
> Since very recently, that has become MUCH easier to do so at least in
> characteristic two. Using the methods described in the paper FGH.ps
> linked from:
>
> http://www.lix.polytechnique.fr/Labo/Mireille.Fouquet/elliptic.html
>
> it is now possible to count points for cryptographic key sizes in
> seconds or minutes with a small standalone program on an ordinary PC.
> We have also gone up as far as 4001 bits using a few days on a fast Alpha.
Thanks for posting the URL, I will pound thru the paper as soon as I can!
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Small hash checksum
Date: 26 Jul 2000 16:57:15 GMT
>Hello,
>
>I am looking for a way to represent a larger checksum like this:
>
>A0D20D19181D1DCF9A0BAADAE496CEB5
>
>with a smaller signature using 4 or 6 characters (e.g. A62D9K or just
>A62T). It doesn't have to secure at all since the two will be placed
>besides each other. It just has to be fairly unique.
>
>I will use it for a fast check, and the larger checksum I will use in
>cases of doubt.
Just use a 32 bit CRC they have the requirements you need.
Table driven implementations are very fast. The code is readily
available. You can pick a wide range of good 32 bit CRCs to avoid
any interaction with the data.
On the down side you would have to process the data twice
if you wanted to verify with the larger hash. Depending on the
security you need MD5 (low) or SHA-1 (high) should do the
job for the second hash. You could also just use some bits of
these as the short hash..
>
>I don't know anything about coding this sort of algorithms, which is
>why am asking here. I just don't thisk I would be able to create a
>unique string on my own.
>
>Kind regards
>ras
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
>
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: George Peters <[EMAIL PROTECTED]>
Subject: Re: Get Free Software
Date: Wed, 26 Jul 2000 16:59:45 GMT
Perhaps you didn't notice the source.zip contained within. Since you make
so many assumptions without first checking them out, I would not take any of
the other comments seriously either.
Mark Wooding wrote:
> George Peters <[EMAIL PROTECTED]> wrote:
>
> > At www.endecs.com/uenigma.exe an entire suite of encryption products
> > is available. Because of specilized setup, it is a self-extracting
> > .exe which you will need to run the setup.exe after extraction.
>
> Oh. This is the sort of `free' software which isn't really free at
> all. No source code, no right to modify the software...
>
> The web page http://www.endecs.com/ is a scary place. It's another of
> these bizarre `secure mail exchange' things.
>
> : This service will provide you and other people signed up for the
> : service the ability to send email and attachments securely.
>
> That's a good idea. So good, in fact, that Phil Zimmerman had it years
> ago.
>
> : The chief benefit from using the service is you don't have to worry or
> : deal with anyone's personal key.
>
> Oh, dear. Alarm bells are ringing by this point.
>
> : It will work like this:
> :
> : * You sign up (no setup fees!) for the service. We will create a
> : profile for you and send your personal key and software to you
> : (similiar to our Eureka Email product). There will only be a $5
> : fee a month for personal and $15 a month for corporate accounts.
>
> Wow! They give me my own key, to save me from choosing a bad one! This
> must be secure.
>
> No, hang on. How do they send me my key, and make sure that nobody can
> read it on the way? I'd recommend using PGP-encrypted email, but that
> rather begs the question of why I'd want to prat about with this EnDecs
> thing. (GnuPG, which is PGP-compatible is proper Free Software.)
>
> : * You encrypt a message and/or attachments using our software
> : (perferrably addressing it to another registered client) and your
> : messages will be sent to us for processing.
> :
> : * We receive the email and using your personal key on file, decrypt
> : the message and/or attachments and if the recipient is also signed
> : up for the service, we'll encrypt it again using the other
> : person's personal key. We'll then send it along for delivery.
> : The person you are sending data to does not have to be registered
> : with the service if no encypted data is being sent.
>
> Ummm... But then they get to read all of my mail. I have to trust them
> not only to write secure software and put proper encryption in it (which
> I don't), but also to handle all of my mail which is too sensitive for
> me to send unencrypted. For as long as I use the service.
>
> Of course, I could use GPG on my messages before sending them to EnDecs,
> but this rather defeats the point.
>
> : * When you receive an encrypted message, you then use your personal
> : key to decrypt the data.
> :
> : Nothing could be easier! Even if you are sending to multiple people,
> : each will arrive encrypted with their own personal key. No shared
> : keys, no key management, no hassles!
>
> No security!
>
> -- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: How is the security of Outlook Express encryption ?
Date: 26 Jul 2000 17:08:51 GMT
>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?
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: "ET" <[EMAIL PROTECTED]>
Subject: looking for s-box generator
Date: 26 Jul 2000 17:23:39 GMT
I am looking for the DES-like S-Boxes generator which
satisfies with 0-1 balanced, output bit independence, SAC,
highly non-linearity, and differential uniformity distribution.
Where can I find such resource?
------------------------------
From: "???" <[EMAIL PROTECTED]>
Subject: Re: How is the security of Outlook Express encryption ?
Date: Thu, 27 Jul 2000 01:39:10 +0800
Actually, I want to know which encryption algorithm and what key lenghth are used by
Outlook Express.
Thanks.
"jungle" <[EMAIL PROTECTED]> ????? news:[EMAIL PROTECTED]...
> 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 ...
>
> you don't need to use your "a piece of software" to get PLAIN TEXT ...
> use any KEY LOGGER instead ...
>
>
------------------------------
From: Tom Anderson <[EMAIL PROTECTED]>
Subject: Re: Get Free Software
Date: Wed, 26 Jul 2000 19:17:28 +0100
On Wed, 26 Jul 2000, George Peters wrote:
> Perhaps you didn't notice the source.zip contained within. Since you
> make so many assumptions without first checking them out, I would not
> take any of the other comments seriously either.
that's a little harsh.
> Mark Wooding wrote:
>
> > George Peters <[EMAIL PROTECTED]> wrote:
> >
> > : * We receive the email and using your personal key on file, decrypt
> > : the message and/or attachments
the key phrases there are "your personal key on file" and "decrypt the
message". they have your key, and they use it. remind me again why we're
supposed to think this is okay?
tom
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Cryptographic Camouflage
Date: Wed, 26 Jul 2000 11:12:10 -0700
> I think the word you want is "steganography" that I thinks means
> information hiding. I do not know its usage history.
> /Steve
Unfortunately it's not appropriate, the use of the word camouflage is a part
of the marketting, and is part of the basis for the patent our product(s)
makes use of. As un update though, we have suceeded in doing more with the
technology, including signing monetary transactions, signing documents, key
negotiation, determining a general usage private key, and we're working on
others. Also client-side key generation is officially released. Needless to
say, with all this new stuff floating around we need more people, so if
anyone needs a new job .. .
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Get Free Software
Date: Wed, 26 Jul 2000 11:22:01 -0700
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
"George Peters" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Perhaps you didn't notice the source.zip contained within. Since
> you make so many assumptions without first checking them out, I
> would not take any of the other comments seriously either.
Perhaps you didn't notice that we already have free software that
doesn't require us to trust you with our e-mails, doesn't require us
to pay for the service, doesn't require us to deal with the
distributor at all after downloading, it's called GPG, and there's
also PGP-freeware.
Joe
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOX8sSGU1cHc10a6vEQJyXACgsZ5Z0jIEYPbQSG03gmFva3HJQ+UAoIH5
Y3OB3e75ssca9RLNWja3km9L
=tZ7J
=====END PGP SIGNATURE=====
------------------------------
Date: Wed, 26 Jul 2000 20:22:04 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: looking for s-box generator
ET wrote:
>
> I am looking for the DES-like S-Boxes generator which
> satisfies with 0-1 balanced, output bit independence, SAC,
> highly non-linearity, and differential uniformity distribution.
>
> Where can I find such resource?
At Toms Homepage:
http://www.geocities.com/tomstdenis/
------------------------------
From: Tom Anderson <[EMAIL PROTECTED]>
Subject: Re: AESC-stream cipher
Date: Wed, 26 Jul 2000 19:32:35 +0100
On Wed, 26 Jul 2000, Jerry Coffin wrote:
> In article <8ljim1$64r$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> > Thank you very much for your investigation.
> >
> > I suppose that your approach measures performance of
> > Input/output file system mostly and not of the
> > Algorithm.
>
> You suppose incorrectly -- if you read what I did, you'll quickly
> realize that part of the way I tested was designed _specifically_ to
> remove this from the equation. It may be that it's somewhat
> incomplete, as Delphi may do I/O a bit less efficiently than the
> "null-encryption" (i.e. copy) program I used to isolate the encryption
> from the I/O. If so, we might see (for example) a difference of 10%
> between my estimate and the real number. I'm _quite_ certain that
> Delphi hasn't messed up the I/O so badly that it's off by a factor of
> 180:1 though.
i think it would be worth writing a test program, identical to the
encryption program but with the encryption function replaced with a noop.
then try it.
> > I would like suggesting following steps.
> >
> > 1. Take any file for encryption with the length of 256 byte.
> > 2. Modify first call to encryption in AlexMainDlg.pas as follows:
> > For I:=0 to NNNN do <call to encryption>
> > 3. Then use stop watch to measure this loop call.
>
> IMO, your suggestions are _quite_ poor. They measure something
> completely UNrelated to the program in real use, leading to a result
> that simply doesn't mean anything, even at best.
the test as suggested is highly bogus, but has one key good feature: the
data is in RAM, so I/O costs go away. of course, you still have memory
access costs, but they are a little smaller.
> Of course, using a
> stop-watch instead of a timer built into the machine is _nowhere_
> close to "at best", but that's a more or less separate question.
i assumed that by 'stop watch' Alex meant a machine timer; surely nobody
in their right mind would suggest using a physical stopwatch?
> > I think that 99% of performance takes key schedule.
> > This is why it is not reasonable to use a script for
> > Multiple starting of the program. The approach above helps
> > to separate performance of encryption algorithm from I/O
> > system and key schedule.
>
> Your approach will produce results that don't give anybody an
> indication of anything useful. I took the results of encrypting a
> single file of approximatly 180 Megabytes. That should involve ONE
> key setup, followed by 180 Megabytes of encryption. I subtracted off
> what it took to simply copy the file, thus eliminating (most of) the
> effects of the I/O speed.
agreed about the key setup, not quite so sure about the IO. you're
probably right with your 10% SWAG, but i have been bitten by ropey IO in
my code (i assume Alex hasn't packed his code with hardcore IO stuff,
whereas the system copy command probably talks to the file system at a
fairly low level (?)).
> If there's any major problem with the approach I took, it's that it
> encrypted a file MUCH larger than most people are likely to encrypt on
> a regular basis. This amortizes the key setup over a larger amount of
> encryption time, which will make your encryption look FASTER than
> anybody can expect to see in most normal uses.
true!
here's the test i would do:
write a function which uses an already set up AOTP cipher to encrypt a
byte of data (AOTP uses bytes, right?). write a function with the same
prototype that just returns the byte unchanged. write a test harness that
sets up a large (as big as your memory can hold - 40 MB is safe on a 64 MB
system) array full of random bytes, sets up an AOTP cipher, then runs
through it N times with the AOTP function and N times with the noop
function, for N ~= 5. use the system timer to time each run of the loop,
and print out the times. post the times, and the data size used, to the
group.
this times just the encryption; it should compensate for memory-access in
the same way that Jerry compensates for IO (it won't quite do it, because
the cpu will probably have to read from memory to get the program code;
one would, however, hope that this gets stuck in the cache fairly
quickly).
Alex, why don't you do this for us? i think most people would respect the
values produced, and it should be pretty easy.
it might also be nice to use the timer to time key setup; since it's
probably quite fast, it might be necessary to set up, say 1000 keys in a
row and measure the time for the lot of them.
> The simple reality is this: there's simply no way to put your
> algorithm to use in such a way that your performance claims have any
> chance of being anywhere close to accurate.
agreed.
tom
------------------------------
From: Tom Anderson <[EMAIL PROTECTED]>
Subject: Re: AESC-stream cipher
Date: Wed, 26 Jul 2000 19:35:49 +0100
On Wed, 26 Jul 2000, Tom Anderson wrote:
> Alex, why don't you do this for us? i think most people would respect the
> values produced, and it should be pretty easy.
oops, forgot to mention: if you could also tell us the BYTEmark score of
your machine, that would be ideal. see:
http://www.byte.com/bmark/download.htm
tom
------------------------------
From: Scott Long <[EMAIL PROTECTED]>
Crossposted-To: comp.security.unix,alt.computer.security
Subject: MD5 algorithm questions
Date: Wed, 26 Jul 2000 11:38:38 -0700
Reply-To: [EMAIL PROTECTED]
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
------------------------------
** 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
******************************
