Cryptography-Digest Digest #45, Volume #9 Sat, 6 Feb 99 20:13:03 EST
Contents:
Re: Engima ("Darren")
Re: What cipher is used by iomega in ZIP products ? ("Else")
SCOTT COMPRESSION ([EMAIL PROTECTED])
Re: Java random (Paul Rubin)
Re: New search utility for this group (Dale R Worley)
Encryption Algorithms (Asher Pressman)
Is there a SHA implementatin in Visual Basic? ("tiglath")
Re: Encryption for telemedicine (Bill Stewart)
Re: Historical basis for BLOWFISH (Bill Stewart)
Re: Java random (Paul Rubin)
Re: Encryption for telemedicine (Michael Sierchio)
Re: Rolling code generators (Paul Rubin)
----------------------------------------------------------------------------
From: "Darren" <[EMAIL PROTECTED]>
Subject: Re: Engima
Date: Sat, 6 Feb 1999 16:11:09 -0000
http://www.geocities.com/CapeCanaveral/Launchpad/6720/
has an Enigma applet with source, not sure if thats what your after
------------------------------
From: "Else" <[EMAIL PROTECTED]>
Crossposted-To: alt.iomega.zip.jaz,alt.iomega.zip.jazz
Subject: Re: What cipher is used by iomega in ZIP products ?
Date: Sat, 6 Feb 1999 22:45:39 +0300
Richard Herring wrote in message <79emqu$733$[EMAIL PROTECTED]>...
>In article <[EMAIL PROTECTED]>, Paul Rubin ([EMAIL PROTECTED]) wrote:
>> In article <[EMAIL PROTECTED]>,
>> Geoffrey Milos <[EMAIL PROTECTED]> wrote:
>> >Can anyone shed some light on which cipher Iomega uses to encrypt data
>> >when a ZIP drive is password protected ? It troubles me that this
>> >info is not revealed on their www site (at least, I couldn't find it
>> >there).
>
>> The data is not encrypted. The passwords are quite easy to defeat.
>
>... using an everyday household object, in fact ;-)
Paper clip?
------------------------------
From: [EMAIL PROTECTED]
Subject: SCOTT COMPRESSION
Date: Sat, 06 Feb 1999 20:43:52 GMT
I think I have stated the next release of a scott encryption
would involve the use of compress below is the out line of
such a method.
One uses compression to maximize entropy per bit. But if
the data already has high entropy here is an approach
that maximizes increases the average entropy while at the
most adding one byte max to any file. So that the file
either greatly compresses or just one byte is added.
First is the simple explanation:
pretend your are doing standard Huffman compression and
that the bit tables are already built. So that for all
8 bit vaules the values of table are the same as the
values used but that the count is zero for all entries.
Next suppose the 8 bit character 00001000
appears as first entry in input file to be compressed
place that value on ouput file as 00001000 now rebuild
the huffman table 000010000 becomes 0 while all the
other entries have a nine bit coding. Now if the input
file has duplicates. for first several bytes you just
start using 0 for each duplicate then when a new character
appears you rebuild off line the table again. When you
get all the way through the file see if ouput file is shorter
than the orginal file if it is place 00 in front of file
if not place 11 in front of file. Know it this point you
have an ouput file that is longer at most by 2 bits.
And you have to keep track of the odd length number of
bits at this point. Know revsere the file end for end
and make a second pass (In real program this is effect
for explantion only you can keep track with out really
swapping file end for end) but add only a single 0 if
compression took place and a 1 bit if compression did
not take place.
If at least 2 bits of compression took place do the first two passes
over in a loop. Continual looping till no gain. (At 2 bit case you
need to check if real gain in next pass so messy but you can
check it.) And 10 is for forward control compression 8 bit pass
all the next times. And 01 is the no compression control bits
for the no compress forward pass 8 bit case.
At this point do the huffman compression as above useing 4 bits
tables where a 0 bit used as control bit to tell if encryption
on 4 bit pass and while 1 for none do same for reverse pass.
Know keep doing 4 bit pass till no gain as above.
Next go to 2 bits pass where 0 and 1 bit used for control
in forward pass but 2bits used in reverse pass since
this is stopping mechanize. At this point use 11 if last pass
no compression and 00 last pass with compress. Not the 2
bit state is only for reverse direction. Loop on 2 bit
as above if loop sucessuful make sure the correct control
bits use on reverse pass since 11 or 00 only last reverse
pass use 10 and 01 if not last pass.
To see if it was the last pass start as if you had a new file
but replace the last control bits with 01 if compression took
place and 10 if compression did not take place.
see if repeating from the top with 8 bit table down to 2 bit
tale if there is any more reduction. If there is continue on
if not use the file saved above.
There is one thing to add to the final file since we only
write files out in BYTES. That is in last byte out on very
last pass have 3 bits that tell which bit the file ended on
if compression actauly took place.
Summary if no compression took place at all then the output
file is "1111 (reverse of original} 1111" where the 111 is
in bits.
control bit summary
forward 8 bit pass 00 compression took place beginning pass
11 no compression took place begining pass
01 compression took place not first time
10 no compression too place not first time
(not first time means the very first pass)
revese 8 bit pass 0 compress
reverse 8 bit pass 1 no compress
forward or reverse 4 bit pass 0 compress
reverse or reverse 4 bit pass 1 no compress
forward 2 bit pass 0 compress
forward 2 bit pass 1 no compress
reverse 2 bit pass 01 compression took place not last thing done
10 no compression not last thing done
00 compression took place last thing done
11 no compression took place last thing done
There are some extra things to consider when one is doing this
compress
1. the control bits you can pick different values than what
I give. since first and last pass use a single cycle S table
2 bits wide. each table has 2.58 bits of info
that leaves 4 more choices of how to use the 0 or 1 for
compress or no compress that addes up to 9.16 bits of info
so that the random selection can increase the average total
entropy of the compressed file.
2. I assumed a particular starting order for the huffman table
this also can be changed and if one went to all the trouble.
to change it then you could use that table as a straight lookup
table for the cases where compression does not occur. That way
even the noncompressed files would have an encryption that is
built into the compressor.
3. Why should one give information to someone based on file
lenght. The starting 8 bit pass assumes that the file is
an nice number of bits divisable by 8 one could have a random
parial byte so that when compression is undone the last pass
will not appear to have a nice number of bits. This would add
to the confuseion when some one is trying to uncompress.
Well Paul Onions, Redburn, Horst, and etc does it seem like
a cryptogahiacally safe compression for use in my
"all or nothing encrytpion" program.
David Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Java random
Date: Sat, 6 Feb 1999 18:42:50 GMT
In article <794ttt$1ka$[EMAIL PROTECTED]>, Else <[EMAIL PROTECTED]> wrote:
>Please comment on this scheme of generating random number in Java:
>
>seed instance of Random as
>
>Random rnd = new Random( System.currentTimeMillis() ^ (new
>Object().hashCode() << 16) );
>
>then
>
>for( int i=0;i<n;i++ )
> rnd = rnd.nextInt( );
>
>where n is a number of times one thread runs while another one sleeps for
>100 ms. It's in the range of 90,000 - 150,000 on my machine.
>
>then I get the random sequence of 16 bytes which I use to generate RC4 key.
>
>This method is some what different from SecureRandom. I can't use
>SecureRandom because takes too much time - over 1 second.
>
>Any suggestions of improvement? Any visible vulnerabilities?
Yes, this method is no good. Say you use it in a web client and the
RC4 key has to be secret from the server, and some other part of the
client timestamps something that get sent to the server. That means
the server can guess the client's clock setting to within a few msec,
so the currentTimeMillis() call is worthless. The "new Object" call
generates a memory address of something which on a PC is 30 bits at best
(4-byte boundary). Then there is the matter of the 48-bit internal
state of Random, as others have mentioned.
------------------------------
From: [EMAIL PROTECTED] (Dale R Worley)
Subject: Re: New search utility for this group
Date: Sat, 6 Feb 1999 22:30:49 GMT
In article <[EMAIL PROTECTED]> BH <[EMAIL PROTECTED]> writes:
New search utility for this group
at:
http://patriot.net/~bhakiz/
It looks like a spam; I tried "panama" and got nothing related to the
Panama crypto algorithm that was discussed here a month ago.
Dale
Dale Worley [EMAIL PROTECTED]
--
The question if a computer can think is as interesting as the question if
a submarine can swim. -- E. Dijkstra
------------------------------
Date: Sun, 07 Feb 1999 01:05:15 +0200
From: Asher Pressman <[EMAIL PROTECTED]>
Subject: Encryption Algorithms
Does anyone know of any good sites where i can find encryption
algorithms? I've been looking for a while and i just can't find
anything...
------------------------------
From: "tiglath" <[EMAIL PROTECTED]>
Subject: Is there a SHA implementatin in Visual Basic?
Date: Sat, 6 Feb 1999 18:13:51 -0500
Thanks.
------------------------------
From: Bill Stewart <[EMAIL PROTECTED]>
Subject: Re: Encryption for telemedicine
Date: Sat, 06 Feb 1999 15:27:50 -0800
(Please email replies; I'm only lurking this newsgroup.)
There are three basic approaches you can take to encryption:
- Encrypt the files and transmit them with standard programs like ftp or
email.
- Set up an encrypted session and transmit files across it.
- Use an existing system that supports encryption
For the first case, use PGP. It's well-established,
well-tested, available free for non-commercial use and
inexpensive for commercial use through PGP's European subsidiary,
and you can get commercial support. It doesn't require a TTP,
so keys can be distributed by end-users, but you can certify keys,
and the commercial versions of the program provide some policy support.
For the second case, the proper solution is to use
Diffie-Hellman key exchange, possibly with authentication,
and either RC4 or a newer algorithm such as Blowfish
to encrypt the stream. Diffie-Hellman has the advantage that
you don't need to distribute keys in advance to generate secure session keys
for use with the fast symmetric algorithms, but if you want to combine the
authentication with the encryption process rather than somewhere else in
the application, you can implement it by signing the DH half-keys.
For the third case, the obvious choice is SSL encryption on a web server,
which uses public keys and X.509 key certificates to establish a session.
There is wide commercial support, and there are free implementations
with the Apache web servers, and the major web browsers all support it.
You can get the SSLeay tool set free, and its developers are now the
Australian subsidiary of RSA Inc.
Bill Stewart, [EMAIL PROTECTED]
Themos Dassis wrote:
>
> I am working in a European project in telemedicine and trying to
> identify the security components that will be needed.
> The system consists of LAN's connected with ISDN reserved lines.
> The LAN's will be Ethernets, while on the ISDN the EURO-ISDN protocol
> will be used. The data communicated is sensitive data related to
> the patient, and quite big (around 70Mbytes). The project is not
> concentrated in security, but we have to implement some kind of
> encryption.
> I was thinking of an ISDN modem with a symmetric encryption hardware
> incorporated to it, but I was told that such a solution is out of the
> trend and that a public key solution with a TTP suits best to my
> problem.
> What kind of a solution would you propose me?
>
> Themos Ntasis
------------------------------
From: Bill Stewart <[EMAIL PROTECTED]>
Subject: Re: Historical basis for BLOWFISH
Date: Sat, 06 Feb 1999 15:37:10 -0800
Bruce Schneier wrote:
> Blowfish was invented after I wrote the first edition of Applied
> Cryptography. It was first presented at the 1st Fast Software
> Encryption workshop on December 1993, and has never been modified.
If I remember correctly, wasn't there a problem with the
C code implementation of Blowfish in either the 2nd edition book
or in the software disks accompanying it?
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Java random
Date: Sun, 7 Feb 1999 00:18:14 GMT
In article <79i41h$lim$[EMAIL PROTECTED]>, Else <[EMAIL PROTECTED]> wrote:
>>If you have a way to load native functions with the JNI, your best
>>bet is to add some system specific code that gets closer to the hardware.
>>Then use something like Yarrow (www.counterpane.com). You can't do
>>that in portable Java, though.
>
>Unfortunately, I cant go native. It's a part of a web client (Forex trading
>terminal) which is given to clients for free on the web.
Why do you need to generate entropy on the client? Is the client
trying to create a secret that it needs to keep away from the server?
If not, how about having a native RNG on the server side and have the
server send some initial PRNG state to the client over the SSL
connection?
>I made an implementation similar to SecureRandom. I setup a counter which
>just goes count++;
>while another thread sleeps for 10 ms. 10 ms is enough for the counter to go
>to a few thousand on an average Pentium. I think it's enough entropy for one
>byte. The whole 16 bytes takes just 160 ms, which is way faster than
>SecureRandom. I think it should be enough for this application.
I'm a little skeptical of this. If the counter goes to a few thousand
in 10 ms, what is the statistical distribution if you do that several
thousand times? Have you looked at that? You might be getting only a
few bits of useable entropy each time, if that much (say the count
reaches 3403 the first time, then 3315, then 3402, etc.) If you're
going to use this method I'd advise collecting all the output of the
counters and hashing it before using it.
I'm not even completely convinced that the numbers from SecureRandom
are really that random if they're for very high security purposes.
But I haven't looked into it that much.
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: Encryption for telemedicine
Date: Sat, 06 Feb 1999 16:26:16 -0800
Reply-To: [EMAIL PROTECTED]
Bill Stewart wrote:
> For the second case, the proper solution is to use
> Diffie-Hellman key exchange, possibly with authentication,
> and either RC4 or a newer algorithm such as Blowfish
> to encrypt the stream. Diffie-Hellman has the advantage that
> you don't need to distribute keys in advance to generate secure session keys
> for use with the fast symmetric algorithms, but if you want to combine the
> authentication with the encryption process rather than somewhere else in
> the application, you can implement it by signing the DH half-keys.
Have a look at how SKIP handles key agreement and authentication -- despite
the lamentable fact that it didn't make it to the IAB Standards Track,
it's widely implemented and has many advantages over ISAKMP/OAKLEY.
if Kij is the shared DH secret, then Kijn is computed where n is a sequence
number (typically hours since 1-Jan-1970 00:00 GMT), and Kij' is the low-order
256 bits of Kij:
Kijn = md5(Kij' + n + 01h) + md5(Kij' + n + 00h)
("+" denotes concatenation). This may be precomputed and is designed
to prevent replay attacks.
Kp, a random symmetric key, is encrypted with Kijn and sent with the packet.
It is not used directly, but is used to derive packet encryption and MAC
keys:
E_kp = md5(Kp | Crypt Alg | 02h) | md5(Kp | Crypt Alg | 00h)
A_kp = md5(Kp | MAC Alg | 03h) | md5(Kp | MAC Alg | 01h)
Crypt algorithms are for e.g. 0x01 - DES-CBC, 0x04 - RC4-128, etc. and MAC
algorithms are 0x01 for 128 bit keyed md5, etc. Obviously if you need only
128 bits you may calculate only the low-order component. As the spec says,
The construction above has the property that knowing either
one of E_kp or A_kp keys does not compromise any information
about the other key because of the one-way property of h().
This allows, for example, weak encryption keys to be used
with strong authentication keys. Should E_kp be compromised,
nothing at all is revealed about A_kp, and vice versa.
So, assuming that the DH public values are known and verified (carried in
X.509 signed certs, for e.g.) then no setup is required other than once
having calculated the master secret Kij which is never used. All other
computation uses hash functions of symmetric crypto.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Rolling code generators
Date: Sun, 7 Feb 1999 00:47:03 GMT
In article <[EMAIL PROTECTED]>,
Robert Scott <[EMAIL PROTECTED]> wrote:
>Can someone point me to a source for an academic treatment of
>rolling code generators? These are the codes used by keyless
>entry system where communication is available in only one
>direction, which precludes challenge-and-response methods.
Doesn't seem like a subject needing much treatment. Garage
door openers are not exactly high security devices.
>I would like to know what are the characteristics of a good rolling
>code generator, and what the relationship might be between rolling
>code generators and conventional encryption algorithms.
Just don't generate predictable codes.
>If you have never considered rolling code generators, their
>applications place unique requirements on them. If you start
>with a key-determined pseudo-random sequence of codes
>from the transmitter, you need to be able to keep the
>transmitter and the receiver synchronized. This is a problem
>for, say, garage door openers. If the kids play with the
>transmitter while it is out of range from the receiver, then
>the transmitter advances without the receiver advancing. So
>when they come back within range, the receiver must be able
>to resynchronize after two or three button presses. But, to
>thwart code-grabber attacks, the receiver must never respond
>to code sequences that it has seen in the past. And all
>this must be implemented in a device that is dirt cheap
>with very little memory.
The transmitter and receiver don't have to be synchronized. Say the
transmitter sends (N,E(N)) where N is a sequence number that it
increments each time and E(N) is an encryption of N under some shared
key so the receiver can check it. The receiver just remembers the
last N that it opened the door for. The receiver doesn't have to
insist that the next attempt use N+1, just that the new number be > N.
It's ok if it's N+2, N+10, or whatever.
Alternatively, the transmitter might not have any state at all. It
just sends some random (R, E(R)). The receiver simply remembers all
the R's that have ever been used. E.g., say R is 20 bits. The
receiver can use a 256 kbit EEPROM (cost under 50 cents) to mark off
the codes as they are used. By the time enough of the memory is full
that you start frequently having to push the button more than once
(say 64k operations = 10 operations/day for 20 years), the rest of the
machinery (opener mechanism, transmitter button, etc.) have long
since worn out.
The systems actually used in garage door openers and car alarms are
actually much more boneheaded even than this.
------------------------------
** 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
******************************
