Cryptography-Digest Digest #796, Volume #8 Thu, 24 Dec 98 16:13:04 EST
Contents:
Re: On living with the 56-bit key length restriction (Lincoln Yeoh)
Re: What is Randomness? (R. Knauer)
Re: What is Randomness? (R. Knauer)
Re: AES candidate performance on the Alpha 21164 processor (version 1) (Harpy-20)
Re: On living with the 56-bit key length restriction (Mike Eisler)
Re: Thanks (was: RC4 questions (8bit/16bit) and CipherSaber-1) ("Trevor Jackson,
III")
Re: Enhancement of EBC mode? (John Savard)
Re: Enhancement of EBC mode? (John Savard)
Re: AES candidate performance on the Alpha 21164 processor (version 1) (Robert
Harley)
Re: Encryption Basics (A C Wilshere)
clipper question (Aleph Software Consulting)
Re: How much of CipherSaber is it OK to post on the web? (was: CS for Dummies) (Paul
Crowley)
Re: clipper question (John Savard)
Re: AES candidate performance on the Alpha 21164 processor (version 1) (Kenneth
Almquist)
Re: On living with the 56-bit key length restriction (wtshaw)
Useful program ([EMAIL PROTECTED])
Re: clipper question (Bruce Schneier)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Crossposted-To: talk.politics.crypto
Subject: Re: On living with the 56-bit key length restriction
Date: Tue, 22 Dec 1998 17:52:42 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 22 Dec 1998 18:06:17 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>These sites are in the US. I am not sure whether there could be
>complications under special circumstances. Hence my advice to use a
>server in countries outside of the 33 to ensure that there will
>never be problems.
Ah, but that wouldn't be the point. I'd like to repeat the point (for
emphasis) that the crypto export law is silly, and the official reasoning
is flawed- e.g. the law is supposedly to prevent criminals/terrorists from
getting their hands on 128 bit crypto. So by definition law abiding people
won't push the button if it's illegal for them to access it.
>> There are various safeguards. I can put MD5 checksums for the stuff, and
>> I've the digital sigs of some stuff too.
>
>How do you know that the stuffs you obtained are without virus?
I don't. I just look at the executables with hiew, and scan em with a virus
scanner. I only give a brief look at the source code. So far I have never
got a virus from the Net. It usually pays not to be the first one to
download things, let other people test things out first.
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: What is Randomness?
Date: Thu, 24 Dec 1998 13:23:19 GMT
Reply-To: [EMAIL PROTECTED]
On 24 Dec 1998 03:33:01 GMT, [EMAIL PROTECTED] (Dr. Yongge Wang) wrote:
>I am sorry, I have just generted the PDF file and it may
>just after you visited it, you are too fast:)
>now it should be threre de.
I got it.
>also please note that the thesis is written in a complete
>different style of Chaitin's method. But the purpose is
>the same and the result should be "equivalent".
If it is about randomness, I want to read it - Chaitin or otherwise.
Bob Knauer
"The police of a state should never be stronger or better armed than the citizenry.
An armed citizenry, willing to fight, is the foundation of civil freedom."
--Robert Heinlein
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: What is Randomness?
Date: Thu, 24 Dec 1998 13:46:37 GMT
Reply-To: [EMAIL PROTECTED]
On 24 Dec 1998 03:33:01 GMT, [EMAIL PROTECTED] (Dr. Yongge Wang) wrote:
>I am sorry, I have just generted the PDF file and it may
>just after you visited it, you are too fast:)
>now it should be threre de.
The downloaded file is not in .ZIP format. I cannot decompress .GZ
files.
Bob Knauer
"The police of a state should never be stronger or better armed than the citizenry.
An armed citizenry, willing to fight, is the foundation of civil freedom."
--Robert Heinlein
------------------------------
From: Harpy-20 <[EMAIL PROTECTED]>
Subject: Re: AES candidate performance on the Alpha 21164 processor (version 1)
Date: Thu, 24 Dec 1998 07:24:31 -1000
Kenneth Almquist wrote:
>
> The Alpha 21164 processor is an interesting platform for comparison
> of AES candidates.
> algorithm cycles rounds * cycles + extra
> -----------------------------------------------
> DFC 304 8 38 0
> Rijndael-128 340 10 34 0
> Twofish 368 16 22.5 8
> HPC 376? 8 47 0
> Crypton 408 12 34 0
> Rijndael-192 408 12 34 0
> RC6 467 20 23 7
> Rijndael-256 476 14 34 0
> CAST-256 600 48 12.5 0
> Serpent 947? 31 30 17
Your conclusion that DFC is fastest appears to be wrong, based on
information that I have reviewed. Perhaps it is the key setup that slows
it down so much. I hope that you will post a follow-up report which
addresses the possibility that you have overlooked a major workload in
DFC which "actual program execution" shows so clearly. You mention that
multiplication makes it slow on other uProcessors, but please consider
that this is not the cause of the speed discrepancy, and that there is
another reason which you have not noticed yet. Also, the results of
the candidates are close to each other in speed for your calculated
speeds, while actual program execution shows a VERY wide variation
in speeds. Thank you for this pseudo-code evaluation. It has helped me to
understand some perceptions of the inner workings of the candidates.
------------------------------
From: [EMAIL PROTECTED] (Mike Eisler)
Crossposted-To: talk.politics.crypto
Subject: Re: On living with the 56-bit key length restriction
Date: 24 Dec 1998 15:36:20 GMT
Reply-To: [EMAIL PROTECTED] (Mike Eisler)
In article <[EMAIL PROTECTED]>,
Lincoln Yeoh <[EMAIL PROTECTED]> wrote:
>On Tue, 22 Dec 1998 18:06:17 +0100, Mok-Kong Shen
><[EMAIL PROTECTED]> wrote:
>>These sites are in the US. I am not sure whether there could be
>>complications under special circumstances. Hence my advice to use a
>>server in countries outside of the 33 to ensure that there will
>>never be problems.
>
>Ah, but that wouldn't be the point. I'd like to repeat the point (for
>emphasis) that the crypto export law is silly, and the official reasoning
>is flawed- e.g. the law is supposedly to prevent criminals/terrorists from
>getting their hands on 128 bit crypto. So by definition law abiding people
>won't push the button if it's illegal for them to access it.
No, the purpose of the law is to prevent GAK-proof encryption from
being ubiquitous. Putting your code on a web site does little toward
ubiquitous encryption.
--
-Mike Eisler Solaris NFS group
[EMAIL PROTECTED] Sun Microsystems, Inc.
remove the prefix 'NO_' and suffix '_SPAM' to reply.
------------------------------
Date: Thu, 24 Dec 1998 11:32:42 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Thanks (was: RC4 questions (8bit/16bit) and CipherSaber-1)
Anonymous wrote:
> Next I shall try to do something (probably only obfuscation-based) to
> thwart what might get left in memory or in the OS swapfile if I press
> Alt-Tab while running my CipherSaber. Infinite circles of snakes eating
> their own tails, don't you know...
You may get better results by defeating the swapfile manager. Parts of the
operating system and certain device drivers cannot be swapped to disk (e.g.,
the swap file manager!), instead they are "locked down" and permanently reside
in memory. You can use this mechanism to make sure nothing ever gets into the
swap file instead of trying to clean it up later.
The fundamental technique is to allocate non-swappable memory instead of
swappable memory. Typically memory exists in "pages" and each "page" has a
bit or two indicating its status. There are techniques for changing allocated
memory from swappable to non-swappable by setting and resetting the status
bit(s), but it is simpler for your purposes to make sure the memory was never
swappable to start with.
The only downside to this is the memory manager is probably buring inside the
run-time of your compiler, and there is no standard way to manage esoteric
features of the underlying reuntime.
For Microsoft (tm) Windows (!tm) you can write a device driver, which is a
pain, or simply ask for "real mode" memory, which is much easier to do. "Real
mode" memory is scarce though, you cannot get a megabyte of it. So use it for
key buffers, and regular memory for everything else.
Note that in 32-bit Windows (!tm), AKA Windows NT, even low memory may be
swappable.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Enhancement of EBC mode?
Date: Thu, 24 Dec 1998 16:53:29 GMT
Marco Stolpe <[EMAIL PROTECTED]> wrote, in part:
>I'm planning to write an application where encryption of files
>is needed but random access to the content of these files is
>necessary.
>- From chapter nine of the book "Applied Cryptography" by
>Bruce Schneier (1996) I concluded that the only thing I can
>do is to use a block cipher with ECB mode.
As others have noted, that isn't quite true.
As has been noted, if you need random access to the files, but in
units of blocks or records, where a block or record is larger than the
blocksize of the cipher you're using, then you can always use CBC mode
within each block or record.
To conceal patterns in the plaintext, where you actually are
restricted to ECB mode, you can always XOR each plaintext block with
its address (perhaps also trivially encrypted). This avoids having to
expand the plaintext at all.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Enhancement of EBC mode?
Date: Thu, 24 Dec 1998 17:08:44 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>Let me point out that it can be a serious mistake to build a system
>which uses a file position in encryption. For example, if the file is
>any form of database, it could not then be re-organized, nor could new
>blocks be "inserted" in the middle. So while this solution may be
>fine for reading static files or ciphering absolute storage, that same
>approach may be inappropriate in a dynamic database.
>One alternative is to store a "block number" value along with each
>block so that it travels with the block. But it would be easier to
>just save an IV for each block.
For the application discussed, altering the data to obscure patterns
by XORing each block with its absolute address need not create a
problem;
data is decrypted whenever it is read, and it is encrypted whenever it
is written.
If an application *not authorized to read the data* were, nontheless,
permitted to re-organize the data, then there would be a problem. This
situation, though, does not occur in many applications: in some, for
example, without the decryption key, not only does one have no idea
where record boundaries are, one also does not know which blocks
belong to a file.
Just as in networks there is a difference between end-to-end
encryption and link-to-link encryption, whole-disk and whole-file
encryption can do certain things, and record encryption can do others.
So one could use CBC mode within a record, and one could use the XOR
of an address relative to the start of the file for file encryption,
and one could use the XOR of a track and sector address for disk
encryption without a problem.
Someone with the disk encryption password only could still copy the
file to another disk without destroying it;
someone with the disk encryption password and the file encryption
password could move records within the file;
and someone with all three keys could modify and read data within a
record.
So it depends on the level where encryption is used what measures are
available to mask against codebook attacks without preventing random
access.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: AES candidate performance on the Alpha 21164 processor (version 1)
Date: 24 Dec 1998 18:28:10 +0100
Harpy-20 <[EMAIL PROTECTED]> writes:
> Kenneth Almquist wrote:
> >
> > The Alpha 21164 processor is an interesting platform for comparison
> > of AES candidates.
> > [...]
>
> Your conclusion that DFC is fastest appears to be wrong, based on
> information that I have reviewed.
Do you seriously expect anyone to care about an appeal to unknown
"information" that you have seen? Either give a proper argument or stop
wasting bandwidth.
> Perhaps it is the key setup that slows
> it down so much. I hope that you will post a follow-up report which
> addresses the possibility that you have overlooked a major workload [...]
And perhaps you should consider the possibility that he hasn't. If
several people have found DFC to be very fast on Alpha, then maybe
that's becuase it actually is.
Rob.
------------------------------
From: A C Wilshere <[EMAIL PROTECTED]>
Subject: Re: Encryption Basics
Date: Thu, 24 Dec 1998 19:40:40 GMT
Hi,
Downloaded Scramdisk (download (v2.02c) compiled .EXE & Manual, I
notice that there is a PGP sig which looks as though it is needed by
Scramdisk, what is the purpose of the sig. I know that PGP requires
a sig to encrypt/decrypt, I assume it carries out a similar function
with this program.
To prevent the loss of encrypted data, what do I need to back up in
Scramdisk, should the program or my hd go belly up. Would a simple
copy of the program folder suffice?
Thanks for the abundance of help so far,
Allan
Seasons greetings and a prosperous new year.
------------------------------
From: [EMAIL PROTECTED] (Aleph Software Consulting)
Subject: clipper question
Date: Thu, 24 Dec 1998 16:28:43 GMT
Can anyone direct me to documentation or patents that covered the clipper
chip that the government was pushing. I am interested in the architecture of
the chip. Any references would be appreciated.
Paul Fronberg
[EMAIL PROTECTED]
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: How much of CipherSaber is it OK to post on the web? (was: CS for Dummies)
Date: 24 Dec 1998 11:57:34 -0000
fungus <[EMAIL PROTECTED]> writes:
> Here we see the stupidity of the laws. I live in a country with
> no restrictions on crypto but what are the legalitys of posting
> my CipherSaber program to usenet?
>
> If the message ends up in IRAQ then who's responsible?
It's Iran (and France, and Russia) that has the overall ban on
domestic crypto.
I had thought that the CipherSaber spirit discouraged the publishing
of implementations in favour of encouraging people to forge their own,
but if that's not so then here's one for those as would like one.
Note that it gives away the time you encrypted the message. Don't
print out the CipherKnight certificate until you've forged your own,
though!
Usage:
./ciphersaber SecretKey 0 < plaintext.txt > ciphertext.cs1
./ciphersaber SecretKey 1 < ciphertext.cs1 > plaintext.txt
#!/usr/bin/perl -0777i.http://ciphersaber.gurus.com
sub S{@s[$x,$y]=@s[$y,$x]}pop==0?print$p=time*2:read STDIN,$p,10;sub
Q{$s[($_[0]+=$_[1])%=@s]}@k=unpack'C*',(pop).$p;for$x(@t=@s=0..255){S
Q$y,$k[$x%@k]+Q$x}$x=$y=0;for(unpack'C*',<>){print chr($_^Q S Q$y,Q$x,1)}
--
__
\/ o\ [EMAIL PROTECTED] http://www.hedonism.demon.co.uk/paul/ \ /
/\__/ Paul Crowley Upgrade your legacy NT machines to Linux /~\
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: clipper question
Date: Thu, 24 Dec 1998 19:53:04 GMT
[EMAIL PROTECTED] (Aleph Software Consulting) wrote, in part:
>Can anyone direct me to documentation or patents that covered the clipper
>chip that the government was pushing. I am interested in the architecture of
>the chip. Any references would be appreciated.
Of course, some information about the chip is still secret. However:
The encryption algorithm it used, SKIPJACK, has been declassified,
along with the public key method for exchanging keys, KEA, and .pdf
documents describing them are available on the NIST web site at
http://csrc.nist.gov/encryption/skipjack-kea.htm
and there is an HTML version at
http://jya.com/skipjack-spec.htm
(My web site also has a description of Skipjack on it, with the .pdf
document as its source, but completely rewritten.)
Dr. Dorothy Denning wrote an article about the Clipper chip for
American Scientist, which described some of the features of the key
escrow system designed to prevent certain forms of abuse.
Other information related to Clipper is on her home page at:
http://www.cosc.georgetown.edu/~denning/
Also, such information as has been publicly divulged concerning the
Law Enforcement Access Field itself is in the 2nd edition of Applied
Cryptography, a book by Bruce Schneier.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (Kenneth Almquist)
Subject: Re: AES candidate performance on the Alpha 21164 processor (version 1)
Date: 24 Dec 1998 18:33:47 GMT
Harpy-20 <[EMAIL PROTECTED]> wrote:
> Your conclusion that DFC is fastest appears to be wrong, based on
> information that I have reviewed. Perhaps it is the key setup that slows
> it down so much. I hope that you will post a follow-up report which
> addresses the possibility that you have overlooked a major workload in
> DFC which "actual program execution" shows so clearly.
It is possible that I made errors in some of the timings. I included
section 3 of my posting precisely so that people could see how I
calculated the times and check my results if they wanted to. However,
I would be very surprised if I had overlooked a major workload in DFC
because the round function is so simple (conceptually). I don't
include the cost of key setup in my numbers for any algorithm.
The "actual program execution" time was for an implementation of DFC
written in C with some inline assembly code, and I don't know how
carefully the programmer tuned the code to match the Alpha architecture.
Some of the things I do to get fast execution of DFC are:
1) For the second reduction module 2**64+13, the DFC paper suggests
using the reduction 13 * ((2**61 - 1) - Q) + 182 - R, using a
table lookup to evaluate 13 * ((2**61 - 1) - Q) + 182. I use the
reduction 13 * Q - R, which is faster on the Alpha.
2) I split many 64 bit values into 32 bit chunks before operating on
them. Operating on two 32 bit values turns out to be more efficient
than operating on a single 64 bit value when the cost of dealing
with overflow is taken into account.
3) I shift the values in the RT table 32 bits left. This allows me
to use the result of the RT table lookup later than it would
otherwise be required. This doesn't affect the number of
instructions executed, but it allows more instructions to be
executed in parallel.
4) The Alpha has a 5 clock penalty if a conditional branch is taken
when the Alpha predicts that the branch will not be taken, or
vice versa. In the code I produced, branch predictions will fail
less than once in a million branches, meaning that this penalty
is trival. A compiler is likely to generate the branches the
other way, incurring the five cycle penalty on almost every branch.
Kenneth Almquist
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: On living with the 56-bit key length restriction
Date: Thu, 24 Dec 1998 12:53:09 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
> If you have really top secrets to be transmitted in time, I am
> not sure that money definitely counts very much for you. Even if
> you have only one single line, you can send the pieces at different
> time points and also use the multiplexing technique that I mentioned
> in the original post. Furthermore, the higher the secret, the lower
> is likely to be the volume.
>
The problem is that most people are not so sophistocated, they either
trust the internet and all its accompaning structure, or they don't. Many
make recognize someone like Gates or the Government either as their friend
or their enemy. The dvil is still in the details; and making people see
that is extremely difficult, much more that they can have an effect of
determining what the details are.
So many will just say encrypt it all, or try to have no security at all.
Needless to say, those that do err or the side of security are more apt to
have more security; it is up to us to see that it is available if wanted,
even on someones whim. Now, encrypting everything is not especially
useful to those who want to filter. Meanwhile, the mere use of marginal
encryption can throw a monkey wrench is such a process, like reversing the
characters in this paragraph:
:hpargarap siht ni sretcarahc eht gnisrever ekil ,ssecorp a hcus si hcnerw
yeknom a worht nac noitpyrcne lanigram fo esu erem eht ,elihwnaeM .retlif
ot tnaw ohw esoht ot lufesu yllaicepse ton si gnihtyreve gnitpyrcne ,woN
.mihw senoemos no neve ,detnaw fi elbaliava si ti taht ees ot su ot pu si
ti ;ytiruces erom evah ot tpa erom era ytiruces fo edis eht ro rre od taht
esoht ,yas ot sseldeeN .lla ta ytiruces on evah ot yrt ro ,lla ti tpyrcne
yas tsuj lliw ynam oS
--
What goes around, comes around.
You reap what you sow.
Do unto others as you would have them do unto you.
The wheels of the gods grind most slowly, but exceedingly fine.
People in glass houses should not cast stones.
Let those who are without sin cast the first stone.
Judge not that ye be judged.
------------------------------
From: [EMAIL PROTECTED]
Subject: Useful program
Date: Thu, 24 Dec 1998 14:26:37 -0600
Reply-To: [EMAIL PROTECTED]
==============5BDDBE9D9CCEC86122A59777
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
File Detect:
File Detect is a Windows 95 program.
This program detects new, modified or deleted files in your disk.
Also detects new or deleted folders (Directories).
This is very useful to know what files (As to be *.DLL's, *.OCX's,
*.TTF's
*.HLP's and many other) are copied to your disk when you install a new
program,
driver or make a change in the system configuration.
As you know, when you install a program or driver in your disk, a lot of
files are installed in your system folders, Some times you uninstall a
program
and these files remain there occupying several MB of space in your disk.
Think about it. How many times do you download a program from the
Internet?.
How many games?.
With File Detect you can take control on this situation since all what
is
copied to your disk is detected.
For more information about this program and for downloading it visit
the home page: www.sinectis.com.ar/u/marsc
==============5BDDBE9D9CCEC86122A59777
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#FF0000" VLINK="#CC6600" ALINK="#FF0000">
<B><FONT SIZE=+1>File Detect:</FONT></B>
<P>File Detect is a Windows 95 program.
<BR>This program detects new, modified or deleted files in your disk.
<BR>Also detects new or deleted folders (Directories).
<BR>This is very useful to know what files (As to be *.DLL's, *.OCX's,
*.TTF's
<BR>*.HLP's and many other) are copied to your disk when you install a
new program,
<BR>driver or make a change in the system configuration.
<P>As you know, when you install a program or driver in your disk, a lot
of
<BR>files are installed in your system folders, Some times you uninstall
a program
<BR>and these files remain there occupying several MB of space in your
disk.
<P>Think about it. How many times do you download a program from the Internet?.
<BR>How many games?.
<BR>With File Detect you can take control on this situation since all what
is
<BR>copied to your disk is detected.
<P>For more information about this program and for downloading it visit
<BR>the home page: <A
HREF="http://www.sinectis.com.ar/u/marsc">www.sinectis.com.ar/u/marsc</A>
</BODY>
</HTML>
==============5BDDBE9D9CCEC86122A59777==
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: clipper question
Date: Thu, 24 Dec 1998 19:14:47 GMT
On Thu, 24 Dec 1998 16:28:43 GMT, [EMAIL PROTECTED] (Aleph Software
Consulting) wrote:
>Can anyone direct me to documentation or patents that covered the clipper
>chip that the government was pushing. I am interested in the architecture of
>the chip. Any references would be appreciated.
The architecturd is classified (which might explain your difficulty in
finding anything). Considerable information on the Clipper Chip was
published, mostly hypothesised or distilled from public sources. I
recommend two books for information:
Schneier and Banisar, THE ELECTRONIC PRIVACY PAPERS,
John Wiley & Sons.
Hoffman, BUILDING IN BIG BROTHER, Springer Verlag.
Both are compilations of articles and essays on, among other things,
Clipper.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
** 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
******************************
