Cryptography-Digest Digest #403, Volume #9 Fri, 16 Apr 99 18:13:03 EDT
Contents:
Re: Extreme lossy text compression ([EMAIL PROTECTED])
Re: Possible Snr-level ugrad paper topic? (Geoff Thorpe)
Re: SNAKE#11 - getting better :-) (Thomas Wu)
Re: Radiation/Random Number question (John Curtis)
Re: Adequacy of FIPS-140 (Terry Ritter)
Re: Verify operation of component? (Terry Ritter)
Re: PGP=NSA (More Evidence) (Mark McCutcheon)
Re: Extreme lossy text compression ([EMAIL PROTECTED])
Re: Blowfish Source Code? (Allan Latham)
Re: Adequacy of FIPS-140 (R. Knauer)
Re: tops9720.zip source code for "Topsecret" (Ollivier Robert)
Re: PGP HowTo ("Steven Alexander")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Extreme lossy text compression
Date: Fri, 16 Apr 1999 18:12:45 GMT
John,
I am very impressed and grateful for your reply.
I think I understand what you mean by a "good hash" based upon your
description of its characteristics. You mentioned two flavors: SHA-1 and
MD5. While I have seen C source code posted for SHA-1 by an individual, I
wondered whether there is any authoritative site where proven source can be
found? Is there a web site that is considered the "Hash Authority".
What about licensing these hashes? Who owns them? Is it considered
freeware, shareware, or what? Or is it more just a programming structure like
a "nested loop" which isn't really owned by anybody?
To answer your question, in actual fact, I DO want to count even a 1 byte
change as a change, so a good hash sounds BETTER than perfect for my needs.
I wonder whether sufficient randomization can be achieved in just 20 bytes
considering the non-random characteristic of my inputted plaintext.
Generally the plaintext is going to be ordinary English language text (like
that found in Usenet or in ordinary Email), so there will be a high
concentration of the 26 letters A-Z upper and lower case, plus spaces and
some punctuation. Can a "good hash" still output sufficiently random results
from that input? Do hash developers run any statistical tests to back up
their theory?
Thanks,
Geoff
In article <[EMAIL PROTECTED]>,
John Myre <[EMAIL PROTECTED]> wrote:
>
> Any good hash (e.g. SHA-1) ought to work. The output is even
> shorter (20 bytes in the case of SHA-1) than requested, and so
> more efficient. The theory is that a good hash seems like a
> "random function" of the input and so the likelyhood of a false
> match (a "collision") is the same as two random values of the
> hash length being the same.
>
> I am taking for granted that in fact you want even a
> tiny (e.g., 1 byte) change to show up as a difference; that you
> don't care if you store umpty-ump versions of the same document.)
>
> [EMAIL PROTECTED] wrote:
> >
> > I have an idea to reduce redundancy in a large data store. When a plaintext
> > is submitted to storage, I want to be able to easily determine whether that
> > exact plaintext already exists in my storage.
> >
> > It would be kind of like an extreme "lossy" compression scheme. We'd be
> > taking up to 10000 bytes of plaintext and creating a 256 byte "key" for
> > matching identical plaintexts.
> >
> > Then when a new plaintext is submitted, I can generate my 256 byte "key" and
> > quickly search my database to determine if that 256 byte "key" exists.
> >
> > Unlike most things discussed in sci.crypt:
> > 1. I don't need to be able to recreate the plaintext from the key.
> > 2. I don't care about security, so headers and things are perfectly fine.
> >
> > Assume I won't be able to compare the original plaintexts to verify
> > that they are actually identical. I need a high degree of confidence based
> > upon the keys alone.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Geoff Thorpe <[EMAIL PROTECTED]>
Subject: Re: Possible Snr-level ugrad paper topic?
Date: Fri, 16 Apr 1999 16:21:35 -0400
Hi there,
> I'm in a senior-level undergraduate Crypto class and I'm looking for a
> topic in crypt that I can write about in a paper (5 pgs.. some math).
> Something different besides the RSA/PGP/entropy/whatever stuff we've
> been doing in class.. Any ideas? Places to look? Thanks.
Elliptic curve crypto? Nice off-beat alternative to the standard x^q mod
n RSA stuff, contains some cute maths, and allows for some way-sexy
diagrams too. Having provided that thought I can't think of any obvious
jumping-off points on your search but probably counterpane.com, or just
haul up altavista and search. Actually check out Peter Gutmann's link
farm (it's somewhere in http://www.cs.auckland.ac.nz/~pgut001/), I seem
to recall some links there about this sort of stuff.
Cheers,
Geoff
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: SNAKE#11 - getting better :-)
Date: 16 Apr 1999 12:16:48 -0700
Peter Gunn <[EMAIL PROTECTED]> writes:
>
> 1) A->B: (g^A)%p, U
> 2) B->A: (g^B)%p
>
> both work out session key K=H((g^AB)%p) which
> is used to encrypt all traffic from now on.
Why bother with an extra key exchange - just use the
session key from the variable-modulus exchange.
> 3) A->B: (g^S)%m(P,K), T
> 4) B->A: (g^R)%m(P,K), V
> 5) A->B: E[(g^RS)%m(P,K)](V)
> 6) B->A: E[(g^RS)%m(P,K)](T)
>
> A and B check values returned against their own
> calculations disconnecting immediately if they dont
> match.
>
> Ok, looks pretty much like SNAKE#10-3 so far,
> doesnt it? Well, the trick is the function m(P,K)...
>
> Let Z by an array of 1999 prime numbers of between
> 2^200 and 2^400, which the client and server have
> agreed upon. The primes are not necessarily safe
> primes.
>
> m(P,K)=Z[H(P,K)%1999]
>
> Yes, basically Im saying have a lookup table.
I don't think 2000 is enough, and then there is the problem
of storing 2000 1024-bit integers everywhere - that's a 512K
file! All the Z[i] entries do need to be primes such that g
is a generator mod Z[i].
> The lookup table could be 'compressed' by selecting
> primes which could be expressed as (2^x)-y and using
> a 2 dimensional array of say 200x10 16bit values
> => ~4K :-)
I think you're overestimating prime density for 1024-bit integers.
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: [EMAIL PROTECTED] (John Curtis)
Subject: Re: Radiation/Random Number question
Date: 16 Apr 1999 19:22:34 GMT
In article <7f4hic$pb4$[EMAIL PROTECTED]> "R H Braddam" <[EMAIL PROTECTED]> writes:
>Actually, questions, plural.
>
>Since radiation-hardened ICs are available it follows that standard ICs are
>affected by radiation. A quick web search finds that soft and hard errors
>can occur in ICs because of radiation.
>
>Does anyone here know of any efforts to make *more* sensitive ICs for the
>purpose of detecting radiation?
>
I don't believe that anyone is, but I haven't done a
search.
I have read a test report in which a RAM manf was accelerating
soft failures by taking a hermetic metal lid package, delidding
the package, painting the bottom of the lid with a paste
containing a radioactive source, then resealing the lid.
I don't recall the failure rates, but there was a very dramatic
increase. Claim was that the particle energy was typical of
soft failure sources, just 10^6 times as frequent events.
>Can anyone here tell me if currently produced static RAM or ROM experiences
>soft errors caused by radiation?
>
Ah, yes. They do. Rates are pretty low, like < 1/10^15, which
is pretty damn good, typical of a very low noise communication
channel. I'm writing from memory, so don't hang me if this
is off a couple of orders of magnitude.
Radioactive impurities in plastic packages wreaked havoc in this
area >10 years ago. It is a well-understood problem, now.
This is why ECC is used on small (few 10's of megabyte) memory
systems. Soft errors are encountered. Computers that execute
bad instructions tend to crash a lot.
>Can anyone here tell me if the Americium 241 (1 microcurie) source used in
>smoke detectors would cause soft (or hard) errors in chips if placed in
>contact with RAM or ROM chips?
>
Don't know. I believe that soft errors can be modelled to
first order as an injection of charge into the RAM cell. I'm
sure that even a sloppy literature search will provide you with all
the research facts you need.
ciao,
jcurtis
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Adequacy of FIPS-140
Date: Fri, 16 Apr 1999 20:02:52 GMT
On Fri, 16 Apr 1999 07:36:38 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>wtshaw wrote:
>> ... In short, we get back to considering the effort and data
>> requirements needed to break a key in given cryptosystems.
>
>Okay, I grant that that is a reasonable metric; now the question
>is how to *measure* this. The cost of a brute-force key search
>only establishes an upper bound, which is useless to us (unless
>it is so low as to already be below our security threshold).
It seems to me that this is true of all cryptanalysis.
We always have brute-force, so that always sets an upper bound. But
even if we find a better attack, that only sets a new, lower, "upper
bound," because it does not rule out even better attacks.
All we can get from any cryptanalysis is an upper bound. That means
we do not know the "true strength" of any cipher. As far as we can
know, any cipher can fail at any time, no matter how well reviewed or
cryptanalyzed it may be. And since our Opponents will not tell us of
their success, we will not know when ciphers fail, so we cannot even
judge the actual risk of failure.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Verify operation of component?
Date: Fri, 16 Apr 1999 20:03:19 GMT
On Fri, 16 Apr 1999 07:35:07 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt Sundial Services
<[EMAIL PROTECTED]> wrote:
>[...]
>I would be suspicious of a DES component that does not supply
>source-code particularly when you can obtain source-code from other
>sources. There is nothing, except hard-work, that the component
>provider should have to conceal.
Already invested hard work is precisely the advantage the provider
would like to keep over the competition. Simple implementation is
probably not patentable, so the only protection available is trade
secrecy.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Mark McCutcheon)
Subject: Re: PGP=NSA (More Evidence)
Date: 16 Apr 1999 13:31:21 -0700
In Message <7f69a4$[EMAIL PROTECTED]> someone using
the name of Charles Booher <[EMAIL PROTECTED]> posted:
> There are only 1,000,000,000 possible PGP key pairs with PGP
> 6.0
>
> One key pair per second on an Ultra Sparc
>
> ! year = 60*60*24*365.25 = 86765.25 Seconds in a year.
Not even close!
(60*60*24)+365.25 = 86765.25
(60*60*24)*365.25 = 31,557,600
With this kind of demonstrated attention to detail, who exactly
is gonna trust your programming skills? Sheesh!
Mark
--
The Ninety-Ninety Rule of Project Scheduling:
The first ninety percent of the job takes ninety percent of the
allotted time, the last ten percent takes the other ninety percent.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Extreme lossy text compression
Date: Fri, 16 Apr 1999 18:58:31 GMT
Dan,
Thank you for your reply.
I'm not clear why secrecy is an issue. Maybe you're using the term "secret"
in a technical sense that I don't understand.
My exact application involves archiving. Imagine a program that would monitor
news articles coming over the wire from AP or Reuters. I want to create a
hash so that I can quickly search a database to determine whether that
particular IDENTICAL newsarticle was ever received previously.
So the whole system is secret, in a sense. The hash results will be created
and stored on a backed closed system without any user interface. Keeping "one
short secret" isn't a problem.
Collision avoidance is my TOP priority. Security isn't. After all, the
writers at AP aren't exactly composing their news stories to try to hack my
system! They're just reporting the news.
The number of articles that might be held in this system could be as many as
100,000 per year at first, growing to 200,000 per year within 5 years. Even
if we purge every 20 years, that pace of growth will create a 1,000,000
article database within the likely life of this system.
I need to know that with 1,000,000 different plaintexts in storage, that the
next new unique article that comes down the pike has the near impossibility of
creating hash identical to a NON-IDENTICAL article that was stored previously.
The probability of two plaintext articles creating the same hash is what I
need to minimize.
It would also be nice if the hash were fast, of course.
Is there some website or resource that you regard as the "Hash Authority"
where I could learn about the different things you mention in your Email. I
need to learn a little about all this, and I don't want to BUG you or the
newsgroup for every last detail.
Thanks for your ideas, and the link to your sample code. I'll check it out!
Geoff
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (D. J. Bernstein) wrote:
>
> Will the results be kept secret? If so, you can use a ``universal hash
> function.'' Universal hash functions are fast and guaranteed secure. See
> http://pobox.com/~djb/hash127.html for sample code.
>
> Even if the results are public, can you keep one short secret? If so,
> you can feed a universal hash function through a function such as
> Rijndael. This is still fast, and it's secure if Rijndael is.
>
> If nothing is secret, you'll have to resort to a ``collision-resistant
> hash function'' such as SHA-1. This is not as fast as a universal hash
> function.
>
Geoffrey Teabo wrote....
> > Briefly, my idea is to process plaintext (from 1KB to 10KB
> > in length), and create, say, a 256 byte "key" that is derived from that
> > plaintext that will be unique with a high degree of certainty.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Fri, 16 Apr 1999 22:46:24 +0200
From: Allan Latham <[EMAIL PROTECTED]>
Subject: Re: Blowfish Source Code?
Try counterpane.com (Bruce Scheier - author of blowfish)
Try ftp://ftp.funet.fi/pub/crypt
There is an intel 86 asm version included in ppdd
Please see http://linux01.gwdg.de/~alatham
I didn't write it but it's very fast.
Best regards
Allan Latham
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> John Dafoe <[EMAIL PROTECTED]> wrote:
> >
> >
> > Jon Kadilak wrote:
> >
> > > I'm not sure if this is the right group to post to, apologies if it is
> > > not. Can someone point me in the direction of some Blowfish encryption
> > > algorithm source code? Or some source code that will encode files with
> > > the Blowfish encryption method.
> > >
> > > --
> > >
> > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > Jon Kadilak The Internet Access Company
> > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >
> > The author of Blowfish, Bruce Schneier's home page is www.counterpane.com and
> > he has info on the algorithm in question.
> >
> > --
> > John Dafoe
> > Director of Internet Communications
> > CyPost Corporation - http://www.cypost.com
> > Strong Encryption Products
> > Suite 101, 260 West Esplanade,
> > North Vancouver, B.C. Canada. V7M 3G7
> > Phone: (604) 904-4422 Ext. 228
> >
> >
> If you are a citizen and resident of the US or Canada, send me your
> PBP public key (RSA only) and I will send you my tiny DOS version of
> BLOWFISH running in the CFB block chaining mode; takes up less than one
> disk sector, although the initialization file containing the digits of
> PI is 8 times as long.
> --
> Robert G. Durnal
> Web pages at www.afn.org/~afn21533
> and members.tripod.com/~afn21533
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Adequacy of FIPS-140
Date: Fri, 16 Apr 1999 21:01:44 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 16 Apr 1999 20:02:52 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
>That means we do not know the "true strength" of any cipher.
How an OTP cipher that uses a key which is generated by a quantum
computer?
Bob Knauer
"I am a great mayor; I am an upstanding Christian man; I am an intelligent
man; I am a deeply educated man; and I am a very humble man."
- Marion Barry, Mayor of Washington DC
------------------------------
From: Ollivier Robert <[EMAIL PROTECTED]>
Subject: Re: tops9720.zip source code for "Topsecret"
Date: 16 Apr 1999 18:31:00 GMT
In article <7f40rp$q9s$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> I did not realize that free speech depended on agreeing with
> the terms of your information. I thought for sure we got
> rid of Hitler and his "mathematicians" in World War II.
> I have read, but do not agree with ALL of your information.
I hereby invoke Godwin's Law. Anything you say now is irrelevant. Nice try.
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
Usenet Canal Historique
------------------------------
From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Re: PGP HowTo
Date: Fri, 16 Apr 1999 14:28:56 -0700
Substantiate your claim! You are becoming a pest. If PGP is broken, prove
it! If SecureOffice is secure, prove it! What algorithm/s does
SecureOffice use? Please tell me it isn't proprietary. Have you ever
broken a cipher publicly? Why are you qualified to build a secure cipher?
Where in PGP's source code does it say that PGP has only 1billion keys? Is
it an implementation error or a deliberate backdoor? Prove it! If you
cannot substantiate any of this, shut the hell up! Nobody in here wants to
listen to your incessant rambling!
-steven
my $.02
Charles Booher wrote in message <7f6f03$[EMAIL PROTECTED]>...
>Don't bother learning to use PGP.
>
>It is already completely cracked by the NSA
>
>Use http://www.filesafety.com/SecureOffice.EXE if you are running MS
>Windows.
>
>
------------------------------
** 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
******************************
