Cryptography-Digest Digest #900, Volume #10 Thu, 13 Jan 00 20:13:01 EST
Contents:
Re: "1:1 adaptive huffman compression" doesn't work (SCOTT19U.ZIP_GUY)
OpenSSL, RC4, & RC5 (Greg)
Re: AES & satellite example (Greg)
Re: Why is EDI dead? Is S/MIME 'safe'? Who and why? (Anne & Lynn Wheeler)
Re: Thawte or Verisign SSL Certificate? (Keith Burdis)
Re: "1:1 adaptive huffman compression" doesn't work (Mok-Kong Shen)
New Crypto Export Regs ("John E. Kuslich")
frequency analysis (Jimmy Ross)
MTOPS Definition and measurement ("John E. Kuslich")
Re: Need some design suggestions for mass encryption (Greg)
Re: AES & satellite example (Christof Paar)
Need sources for cryptology / security ("Roger W. Winget")
Re: Truly random bistream (Tim Tyler)
Re: UK Government challenge? (John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Date: Thu, 13 Jan 2000 22:53:55 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>
>> If the one intercepting konws your compression program there has to
>> be a means to seperate where the compression ends and the random
>> data begins. If one does that then the added random information did nothing.
>> Better to use a 1-1 compression where the data is compressed to fit the
>> spave available and where no extra info is added. Since the decompression
>> program most be able to seperate out this random stuff anyway.
>
>Sorry, I don't yet understand. The compression software is public.
>Everyone can have it. Yes, the software has the additional work
>to get appropriate filling bits and to put these in on compression
>and to throw these away on decompression. (The software 'knows'
>how it is to be done.) But are you arguing that's too much
>computational work or what? I don't think that's too much work.
>I have never said that my proposal is 'better' than any 1-1
>compression scheme, only that it 'suffices' for the (practical)
>purpose at hand. Now that you and some people else have developed
>1-1 compressors, one can certainly (or even better) use these (at
>least theoretically more satisfying) products. But on retrospect,
>if my proposal were put forth earlier, there would be in my humble
What humble opinion
>view no absolute 'necessity' to develop the 1-1 compressors, as far
>'practical needs' (in contrast to theoretical desires) are concerned.
>Have I explained the essential points of a previous follow-up
>clearly enough here?
No you haven't explained it well enough
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: OpenSSL, RC4, & RC5
Date: Thu, 13 Jan 2000 21:58:22 GMT
As I understand it, RC4 & RC5 comes as part of the free
OpenSSL software. Yet, RSA charges royalties for RC4
and RC5 in their crypto library.
Is this correct? Can I use RC4 or RC5 freely if I simply
do not want the RSA logo on my software?
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: AES & satellite example
Date: Thu, 13 Jan 2000 22:00:54 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> Greg <[EMAIL PROTECTED]> wrote, in part:
>
> >But an expensive mil bird would be a very strong candidate. Or do
> >you think that the military would use something other than AES
> >finalists?
>
> They already do.
>
> There's this little Federal agency called the NSA, that has thousands
> of America's top mathematicians working for it, with experience in
> cracking the ciphers of other nations, and a huge body of specialized
> knowledge which is kept secret...and it designs the ciphers used by
> the U.S. military. Without telling the world anything about the
> algorithms used.
>
> Because their in-house expertise exceeds that available in the open
> academic community, they can get away with doing that and still have
> secure ciphers.
I am impressed.
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Why is EDI dead? Is S/MIME 'safe'? Who and why?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Thu, 13 Jan 2000 22:18:16 GMT
On Fri, 14 Jan 2000 00:43:36 +0800, sb5309 <[EMAIL PROTECTED]> wrote:
| What is "remote document processing business - invoices, price-lists,
| technical drawings etc." ?
|
| I am curious. Thanks
there are printer outsourcers with locations around the country ...
that are used by lots of industries ... including computer software
vendors; somebody can call their vendor of choice and order a manual;
the request is routed to the printing plant closest to the requester
... and the manual is printed "just in time" and shipped directly to
the requester.
these print oursourcers also handle big batch jobs like monthly bills
& statements. Large percentage of bills, statements, etc are
outsources to these 3rd party printers (i.e. in some locals, nearly
all utility bills/statements are outsourced; i.e. water, sewage,
garbage, power, etc).
Batch bill/statement input tends to be tape ... frequently in some
sort of 1403 or AFP format ... which is then processed for printing
(the print house may even have to have specialized per-client data
extraction to get name/address out of the bill/statement data for
envelope printing).
--
Anne & Lynn Wheeler | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
------------------------------
From: Keith Burdis <[EMAIL PROTECTED]>
Subject: Re: Thawte or Verisign SSL Certificate?
Date: 13 Jan 2000 22:18:47 GMT
Richard A. Schulman <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> wrote in message
> news:84rjt6$6d3$[EMAIL PROTECTED]...
>> 1) Is it necessary to pay a company such as Thawte or Verisign for a
>> certificate? If so, which company's better?
> Verisign now owns Thawte.
This deal is being challenged. See the slashdot article at:
http://slashdot.org/article.pl?sid=00/01/11/1029235&mode=thread
The summary says:
"Independent Online has a report that Entrust Technologies is
challenging Verisign's buyout of Thawte consulting. Verisign is the
world's largest SSL Certificate issuer, with 60% of the market, with
Thawte the second-largest, with about 40%. Combined, they own 99% of
the market.
> Richard Schulman
I'd say go with Thawte. But then I'm South African :-)
- Keith
--
Keith Burdis - MSc (Computer Science) - Rhodes University, South Africa
IRC: Panthras JAPH QEFH
---
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Date: Thu, 13 Jan 2000 23:43:51 +0100
SCOTT19U.ZIP_GUY wrote:
>
> <[EMAIL PROTECTED]> wrote:
> >SCOTT19U.ZIP_GUY wrote:
> >>
> >
> >> If the one intercepting konws your compression program there has to
> >> be a means to seperate where the compression ends and the random
> >> data begins. If one does that then the added random information did nothing.
> >> Better to use a 1-1 compression where the data is compressed to fit the
> >> spave available and where no extra info is added. Since the decompression
> >> program most be able to seperate out this random stuff anyway.
> >
> >Sorry, I don't yet understand. The compression software is public.
> >Everyone can have it. Yes, the software has the additional work
> >to get appropriate filling bits and to put these in on compression
> >and to throw these away on decompression. (The software 'knows'
> >how it is to be done.) But are you arguing that's too much
> >computational work or what? I don't think that's too much work.
> >I have never said that my proposal is 'better' than any 1-1
> >compression scheme, only that it 'suffices' for the (practical)
> >purpose at hand. Now that you and some people else have developed
> >1-1 compressors, one can certainly (or even better) use these (at
> >least theoretically more satisfying) products. But on retrospect,
> >if my proposal were put forth earlier, there would be in my humble
> What humble opinion
If you consider modesty is bad, then substitute it with 'my high
opinion'. o.k. for you now??
> >view no absolute 'necessity' to develop the 1-1 compressors, as far
> >'practical needs' (in contrast to theoretical desires) are concerned.
> >Have I explained the essential points of a previous follow-up
> >clearly enough here?
>
> No you haven't explained it well enough
Another trial: My proposal is able to satisfy the requirement you
originally raised, i.e. to give the analyst no information via
the decompression-(re-)compression process. Hence, if that is
implemented, then there is no necessity to spend time and energy to
develop 1-1 software of the sort that you have done. And further I
am of the opinion that the benefit of having that software isn't
worth the time and energy you and others have spent in developing
the software.
M. K. Shen
M. K. Shen
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: New Crypto Export Regs
Date: Thu, 13 Jan 2000 15:54:08 -0700
Anyone know where to find the "New" crypto export rules released today??
I looked at the BXA site and they seem to have not heard about crypto.
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: Jimmy Ross <[EMAIL PROTECTED]>
Subject: frequency analysis
Date: 13 Jan 2000 23:00:14 GMT
Does anyone know where I can find the relative frequencies of the
characters of the English alphabet in English text?
Thanks,
Jimmy
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: MTOPS Definition and measurement
Date: Thu, 13 Jan 2000 16:21:37 -0700
Does anyone know the definition of MTOPS (a measure of computer speed)
for the purposes of export controls of high speed computers??
Exactly how is this measured??
So what is a theoretical operation? Is it the execution of one machine
instruction or is it one cycle of microcode or what??
Is there any official software out there for benchmarking against
MTOPS??
JK
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Need some design suggestions for mass encryption
Date: Thu, 13 Jan 2000 23:36:29 GMT
> > Hey there crypto-heads, I need some help.
> >
> > My company has commissioned me with a daunting task. We deal with
> > highly sensitive private information (phone, credit card #, addy,
etc..)
> > and we want to save it on our DB encrypted. But there are certain
> > things that have to happen. For example, I'm allowed to share my
phone
> > number or address with certain people, kind of like a group
> > phonebook... So I would need to allow them access at any time.
Yes, I
> > know, sounds like a Public key deal, where I just encrypt with all
the
> > public keys that I want to have access to my stuff. But I need to
be
> > able to revoke access from certain people at any given time. So is
> > there any way to design this smartly, where I don't have to
basically
> > decrypt, reencrypt with one less key, just to deny someone who use
to be
> > on my access list? Also, Public key crypto is slow, I'm not sure
this
> > is something that public crypto can do on the fly, fast enough. I
would
> > need to use something that's really fast. So any suggestions are
> > welcome!
>
> You are mixing two separate and distinct functions. The encryption
of the
> data is not necessarily related to the permission to decrypt the
data. Thus
> I suggest you need two layers, the top to manage access permissions
> (awarding keys) and the bottom to perform encryption with those keys.
>
> This is a tough area. And you can easily create a maintenance
nightmare out
> of your fuzz specs. So KISS your initial efforts to death.
I would agree. In fact, as I began to read through the original
post, my first thought was that the crypto was to be used mostly
to protect the DB information from people who have taped backup
copies. To restrict or grant permissions to individual users or
groups of users is an entirely different issue and crypto doesn't
seem to be a main contributer in it solution.
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Christof Paar <[EMAIL PROTECTED]>
Subject: Re: AES & satellite example
Date: Thu, 13 Jan 2000 18:32:39 -0500
> In article <85h5qo$si6$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
>
> [ ... ]
>
> > > This probably helps a little, but only a little. [...]
> > > IOW, if you're going to allow updating of the code, you certainly want
> > > to use a separate algorithm, but even at best this is only a _minor_
> > > improvement, not a real cure for the fundamental problem.
> >
> > Do you think so?
>
> Yes.
>
> > I was thinking that this might help a lot. The special algorithms
> > used for code uploading will be used only very rarely, and are not
> > performance-intensive, so they could be (e.g.) 1000 rounds of Triple-DES,
> > if you like.
>
> Unfortunately, 1000 rounds of triple-DES isn't any more provably
> secure than what we started with. In fact, it might even be less
> secure for all we really know.
>
> The whole basic notion is fundamentally flawed in any case: as was
> stated to start with, the extra storage for multiple algorithms is
> insignificant as long as you're dealing with a software
> implementation. If you're dealing with a hardware implementation, you
> have two choices: you use either hardwired logic, or else you use
> something like FPGAs.
>
> FPGAs would allow on-the-fly reprogramming of the hardware.
> Unfortunately, FPGAs have much lower circuit density than hard-wired
> chips. Unless you expected to require something on the order of
> _hundreds_ of different algorithms, it's a near certainty that simply
> hardwiring ALL the algorithms would still require less chip area,
> power, etc., than having enough gates of FPGA to implement any one
> algorithm.
As you say, whether FPGA + configuration library or ASIC with all
algorithms is larger/cheaper/less power depends heavily on the number of
algorithms you want to support. However, I have some doubts that the cross
over point is in the 100s of algorithms. A single AES algorithm can be
fairly large in an ASIC, especially if you have to do pipelining etc. for
speed reasons. Note that many modern block ciphers require FAR more area
than DES. At the same time, the AES algorithms can be implemented pretty
comfortably on current FPGAs at very high speeds (Gbit/sec range).
However, note that traditional hardware does in no case allow algorithm
upload which is an attractive option for various reasons.
I believe it is important to not forget about HW implementation (ASIC or
FPGA) since many modern applications have channel speeds that can not be
supported by SW implementations.
Don't get me wrong: I principally agree that traditional ASICs can do a
better job in many cases, but one has to look carefully at the actual
system.
Cheers,
Christof
! WORKSHOP ON CRYPTOGRAPHIC HARDWARE AND EMBEDDED SYSTEMS (CHES 2000) !
! WPI, August 17 & 18, 2000 !
! http://www.ece.wpi.edu/Research/crypt/ches !
***********************************************************************
Christof Paar, Assistant Professor
Cryptography and Information Security (CRIS) Group
ECE Dept., WPI, 100 Institute Rd., Worcester, MA 01609, USA
fon:(508) 831 5061 email: [EMAIL PROTECTED]
fax:(508) 831 5491 www: http://www.ece.wpi.edu/People/faculty/cxp.html
***********************************************************************
------------------------------
From: "Roger W. Winget" <[EMAIL PROTECTED]>
Subject: Need sources for cryptology / security
Date: Thu, 13 Jan 2000 23:51:05 GMT
Aloha!
I am a senior in Computer Science at Brigham Young University - Hawaii.
In order
to graduate, I need to write a research paper relating to my field of
study. I chose
the topic of security in the information age.
I am seeking sources of information on cryptology. I especially look
forward to
materials explaining the security / time to compute ratio of different
algorithms.
I thank you a thousand times in advance.
Mahalo,
Roger W. Winget
mailto:[EMAIL PROTECTED]
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Truly random bistream
Reply-To: [EMAIL PROTECTED]
Date: Fri, 14 Jan 2000 00:25:36 GMT
Guy Macon <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
:>Nobody can measure resistance with the accuracy required. It takes
:>time to measure resistance. The more accurate you want to be, the
:>longer you have to observe for. Without measurement, you can't
:>confirm the resistance of the entity in question to the satisfaction of
:>anyone else.
: Would a superconducting ring with a current going round and round
: for months or years be good enough for you? Got that. Would a
: magnetic field measurement an one day equalling one at six months
: being as close as we can measure help? Got that too.
No, none of these things would be good enough for me. Resistance
mesaurements may get more accurate with time, but for *infinite* accuracy,
you would appear to need infinite time.
It appears that as nature abhors a vacuum, so science abhors certainty.
At no point can you say that your equipment is offering zero resistance,
or was doing so at any particular time in the past - you have no certain
way of knowing what it's doing.
It is much the same as with random numbers. You can apparently construct
patterns with arbitrarily high entropy-ber-bit contents, and that appear
to observers to have no detectable pattern - the equivalent of currents
circulating for large periods of time - but you'll never actually obtain
"true" randomness.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Every time I lose weight, it finds me again.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: UK Government challenge?
Date: Fri, 14 Jan 2000 00:53:07 GMT
On Thu, 13 Jan 2000 16:06:06 -0000, "Tim Wood" <[EMAIL PROTECTED]>
wrote:
>A news article about a GCHQ Crypto challenge:
>http://news.bbc.co.uk/hi/english/uk/newsid_601000/601960.stm
>you'll laugh...
Their site must be busy...I had a real problem, and couldn't get the
page to load at all.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
** 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
******************************
