Cryptography-Digest Digest #400, Volume #9 Fri, 16 Apr 99 04:13:03 EDT
Contents:
Re: Radiation/Random Number question (Jerry Coffin)
Re: True Randomness & The Law Of Large Numbers (Dennis Ritchie)
Paul Koning IS AN IDIOT!! ("Charles Booher")
Re: PGP 6 is JUNK ("Charles Booher")
Re: Adequacy of FIPS-140 ([EMAIL PROTECTED])
Re: PGP 6 is JUNK (Paul Rubin)
Paul Koning is still an IDIOT!! ("Charles Booher")
PGP IS GARBAGE ("Charles Booher")
Is public key crypto just Snake Oil?? (Kenneth Almquist)
Re: HEY STUPID!!! (fpnknvad)
Re: HEY STUPID!!! (Boris Kazak)
Re: PGP, The Big Lie (Theorem with Incomplete Proof) ("Charles Booher")
Re: Please Check my math ("Charles Booher")
Re: Can someone think this through, please. (PGP) ("Charles Booher")
Re: Random Walk (Earth Wolf)
Re: Random Walk (Earth Wolf)
Re: PGP HowTo ("Charles Booher")
Re: One-Time-Pad program for Win85/98 or DOS (Earth Wolf)
Possible Snr-level ugrad paper topic? (Tim Darling)
Re: Can someone think this through, please. (PGP) ("Douglas A. Gwyn")
Re: Adequacy of FIPS-140 (wtshaw)
Re: Adequacy of FIPS-140 (wtshaw)
Re: Adequacy of FIPS-140 ("Douglas A. Gwyn")
Re: Adequacy of FIPS-140 (wtshaw)
Re: Comments to DOJ re NICS (Paul Rubin)
Re: Adequacy of FIPS-140 (wtshaw)
Re: AES Round 1 deadline: 15th April 1999 (wtshaw)
Re: Adequacy of FIPS-140 (wtshaw)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Radiation/Random Number question
Date: Thu, 15 Apr 1999 21:06:10 -0600
In article <7f4hic$pb4$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Does anyone here know of any efforts to make *more* sensitive ICs for the
> purpose of detecting radiation?
If they have, I've never heard of it.
> Can anyone here tell me if currently produced static RAM or ROM experiences
> soft errors caused by radiation?
It's _awfully_ rare. The biggest problem was with dynamic RAM. At
one time, they obtained pure aluminium for casings from melted-down
parts aircraft from the WW-II/Korean War era. They used radioactive
materials for glow-in-the-dark needles on gauges.
> 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?
I'd be pretty surprised if it would, though I've never tested to find
out.
> What if the chips were obtained as dice, or as dice bonded to the bottom
> half of the package and pin connections made... would the passivation layer
> block alpha radiation?
I can hardly imagine a passivation layer affecting radiation enough to
notice.
> If radiation causes picking or dropping of bits in RAM or ROM chips and
> doesn't cause catastrophic failure of the chip, wouldn't this be a useable
> bit source for desktop computers for generating random numbers?
Long before you got to the point that you could plan on using it as a
random number generator, you'd either have a rather heavy computer or
you wouldn't be able to work very close to it.
Keep in mind that when memory problems were at their worst, we still
only saw problems on an order of a couple of bits per week in a half
meg or so of memory. You'd have to raise the radiation level a LOT
before you could plan on any particular bit becoming anywhere close to
random within a reasonable period of time.
------------------------------
From: Dennis Ritchie <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Fri, 16 Apr 1999 03:29:09 +0100
Reply-To: [EMAIL PROTECTED]
R. Knauer wrote:
...
> As Devil's Advocate I hide behind a facade of amateurishness, but I
> could just as well be quite knowledgeable of the subject matter at
> hand and not be letting on.
I assure you that you maintain your facade well. Contratulations.
Dennis
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: Paul Koning IS AN IDIOT!!
Date: Thu, 15 Apr 1999 19:57:25 -0700
2142662119746477066545291275891345409590167750872742653545234523452345234523
4659
Is Prime
Can Paul Konig give me the next ten prime numbers after that?
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: Re: PGP 6 is JUNK
Date: Thu, 15 Apr 1999 19:58:06 -0700
No,
Charles Booher is doing the positing.
PGP IS CRACKED BY THE NSA!!
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Adequacy of FIPS-140
Date: Fri, 16 Apr 1999 02:18:49 GMT
[EMAIL PROTECTED] wrote:
> The very important subjects of decoherence and error correction are
> discussed at length in Williams & Clearwater (op. cit.) and methods to
> overcome them are proposed. Whatever the actual methods are, they will
> be part of the design. IOW, you cannot have a half functional quantum
> computer - it is either fully functional or it is not a quantum
> computer, because decoherence and errors destroy the quantum state.
So this quantum computer, which you claim will provide "provably secure"
random numbers, seems to depend on error correcting codes for proper
functioning.
Knauer, you may not be aware of this, but ECC's aren't perfect. [Well,
some are, but the definition of 'perfect' isn't what you might think.]
What this means is that there are error patterns which simply can't
be corrected **or detected**. True, one push the probability of
these events as low as one wishes ... but the probability is never zero.
Can you explain the impact of this result has on the likelihood of generating
"true randomness", which seems to be the source of these "provably secure"
numbers?
============= 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: PGP 6 is JUNK
Date: Fri, 16 Apr 1999 03:05:25 GMT
In article <7f681m$[EMAIL PROTECTED]>,
Charles Booher <[EMAIL PROTECTED]> wrote:
>I may be crazy, but I am not stupid.
I begin to wonder.
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: Paul Koning is still an IDIOT!!
Date: Thu, 15 Apr 1999 21:35:27 -0700
The Following numbers are all prime. Can you do this with PGP???
2142662119746477066545291275891345409590167750872742653545234523452345234523
4949
2142662119746477066545291275891345409590167750872742653545234523452345234523
5219
2142662119746477066545291275891345409590167750872742653545234523452345234523
5289
2142662119746477066545291275891345409590167750872742653545234523452345234523
5309
2142662119746477066545291275891345409590167750872742653545234523452345234523
5513
2142662119746477066545291275891345409590167750872742653545234523452345234523
5691
2142662119746477066545291275891345409590167750872742653545234523452345234523
5979
2142662119746477066545291275891345409590167750872742653545234523452345234523
5993
2142662119746477066545291275891345409590167750872742653545234523452345234523
6201
2142662119746477066545291275891345409590167750872742653545234523452345234523
6287
2142662119746477066545291275891345409590167750872742653545234523452345234523
6579
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: PGP IS GARBAGE
Date: Thu, 15 Apr 1999 21:42:43 -0700
500 Bit RSA KEY. I did this demo with SecureOffice in under 3 minutes.
SecureOffice will generate any key size RSA key, so if you have some
favorite prime numbers please send them to me and I will make a key for you.
Of course you can make your own prime numbers and keys if you download
SecureOffice yourself.
P=1774725251234966637339380012083468721321597245511085896602988130731
Q=7569435773782970415727710844144531094853860400204245152212389360267
N=13433668805333926260900128506355361862597828882492788797690721289767251249
650582956762623035095344134596686417851343723678551253065177
E=43568437257941881275755468287238052534590225786356233684310260452144419300
372989421639322078185376105569875231639227836860404152963
D=12461592992593747285423271773322726322821226911282168593896296961359839829
385337378029252385113058629734921467711356386738541402057647
M=74852217790578909101761289961183589496556298191711260201824840997411298856
05318254254157423511618208470180539749636723909131728554920
C=12003823404095037730942009161967328940971083015375984319560876274941774902
707220395752699069193610838065962159111507756939704725707988
Please check if the following are true:
N=P*Q
(E*D)%((P-1)*(Q-1)) == 1
C=M^E%D
M=C^E%D
Then try to perform this operation with these exact numbers using PGP.
------------------------------
From: [EMAIL PROTECTED] (Kenneth Almquist)
Subject: Is public key crypto just Snake Oil??
Date: 16 Apr 1999 02:56:27 GMT
Peter Gunn <[EMAIL PROTECTED]> wrote:
> Anyways, the problem is simple... you can only verify a signature
> from someone who you're not familiar with by checking with some
> trusted authority to make sure the public key is owned by whoever
> claims to be the author, and not a person-in-the-middle.
>
> If this is the case, wouldnt it be simpler to have a traditional
> username/password account with the trusted authority, and
> send them the hash for a document you want to sign, and
> have them return a signature of the hash encrypted using
> some 'private key' unknown even to you. Similarly, people
> could verify the signatures by simply sending off the signature
> and your username, and receive the hash for the document
> which they could then check.
You want a private key which is shared with the trusted authority,
rather than a password, if you are concerned about eavesdropping
or man in the middle attacks on your communications with the
trusted authority. The trusted authority also needs to provide
some additional operation if you want the full functionality
provided by a public key system (such as the ability to produce
a message that can only be read by person X). These details
aside, you are correct about the following points:
1) Without a trusted authority, public key systems are of
limited use.
2) If you have a trusted authority, you can implement all
of the functions provided by a public key system using
only private key cryptography.
Why bother with public key cryptography, then? The answer is
that it places fewer demands on the trusted authority.
First, with private key cryptography, users normally have to
contact the central authority more frequently. With public
key cryptography, you can download another individual's public
key once, and use it as many times as required, whereas with
the private key scheme you describe, you have to contact the
trusted authority each time you want to verify the signature
on a document. This means that the trusted authority has to
be able to handle many more queries than it would if public
key cryptography were used. It also means that higher
reliability is required, since the impact of the trusted
authority becoming temporarily inaccessible is higher.
Second, and more important, private key cryptography places
stronger security requirements on the trusted authority. With
private key cryptography, if someone steals the list of private
keys held by the trusted authority, security is broken. With
public key cryptography, depending on the details of the key
management system, an attacker either has to change the keys
held by the trusted authority (replacing your public key with
a different one) or steal the trusted authority's private key.
One way to protect against compromises of the trusted authority
is to have several trusted authorities. This can be done with
private key cryptography, but the number of communications
required discourages it. For example, to extend your signature
scheme to use two trusted authorities, you would have contact
both authorities each time you signed, or verified the signature
of a document. (Well, the verifier could contact only one of
the authorities if s/he wanted to trade security for speed.)
With a public key system, the verifier can get the public key
from two authorities once, and verify that they are the same,
or can get the key from one authority, but verify that the key
has been signed by two trusted authorities.
For these reasons, it should be easier to achieve a given level
of security when using public key cryptography than when using
private key cryptography, thus making public key cryptography
the logical choice now that the patents are expiring.
Kenneth Almquist
------------------------------
From: [EMAIL PROTECTED] (fpnknvad)
Subject: Re: HEY STUPID!!!
Date: Fri, 16 Apr 1999 04:31:29 GMT
On Thu, 15 Apr 1999 20:00:59 -0700, Charles Booher <[EMAIL PROTECTED]> wrote:
> If you do not like my attitude it is probably because your work for the NSA.
Damn, he found out. What do we do now guys? Use the space laser or send the
men in black?
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: HEY STUPID!!!
Date: Thu, 15 Apr 1999 20:04:59 -0400
Reply-To: [EMAIL PROTECTED]
Charles Booher wrote:
>
> If you do not like my attitude it is probably because your work for the NSA.
$$$$$$$$$$$$$$$$$$$$$
Whoever you are, you are missing the point...
Everybody understands that you are impersonating Charlie Booher
with the sole purpose to smear his image from top to bottom.
It is irrelevant, whose agenda you push forward, NSA or China's.
But ... one cannot pretend to be intelligent, and one cannot
pretend to be sober. If you are an idiot, that's forever, if you
are drunken, you stink.
So shut up, don't waste effort anymore, it's in vain.
Without respect BNK
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: Re: PGP, The Big Lie (Theorem with Incomplete Proof)
Date: Thu, 15 Apr 1999 21:49:56 -0700
> Since you bring it it, I can ask: What is the status
> of that situation. I have not heard lately.
They dropped me. Too bad, I was looking forward to presenting my arguments
in front of the US Supreme court.
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: Re: Please Check my math
Date: Thu, 15 Apr 1999 21:52:14 -0700
>
> Consider it check(mated).
>
I assume that since you have a big calculator and that you do not wish to
post an email address to this fine group of scholars and scientist that you
work for the NSA?
You assholes were even stupid enough to try to sabotage my email!
I have a tamper protection in the system now boys.
I really love it when I flush you to the surface!
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: Re: Can someone think this through, please. (PGP)
Date: Thu, 15 Apr 1999 21:57:02 -0700
The NSA has already computed, sorted, and indexed all 1,000,000,000 possible
PGP DF key pairs that can be computed using PGP 6
The NSA can read your PGP email without any problem at all.
------------------------------
From: [EMAIL PROTECTED] (Earth Wolf)
Subject: Re: Random Walk
Date: Fri, 16 Apr 1999 04:42:13 GMT
On Sat, 20 Mar 1999 12:18:47 -0600, Medical Electronics Lab
<[EMAIL PROTECTED]> wrote:
>So why don't you build us a "crypto-grade random" generator
>and prove it is that without using statistics tests. I bet
>there are a lot of people around the world who'd be *very*
>interested!
Depends on what you mean by "crypto-grade random". If you mean a
generator that is provably secure, no such thing exists (yet). If you
mean one that is at least as secure as some commonly accepted
encryption system (such as RSA), they have existed at least since I
wrote my Master's thesis in 1990. (Or has Yao's theorem been disproved
since then? I haven't really kept up with the literature as much as I
should have.)
Earth Wolf
------------------------------
From: [EMAIL PROTECTED] (Earth Wolf)
Subject: Re: Random Walk
Date: Fri, 16 Apr 1999 04:42:15 GMT
On Sun, 21 Mar 1999 11:42:25 GMT, [EMAIL PROTECTED] (R. Knauer)
wrote:
>.... In fact, we know that it is impossible to make a
>"Perfect TRNG".
No, it's not.
Earth Wolf
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: Re: PGP HowTo
Date: Thu, 15 Apr 1999 21:58:36 -0700
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.
------------------------------
From: [EMAIL PROTECTED] (Earth Wolf)
Crossposted-To: alt.security,alt.privacy
Subject: Re: One-Time-Pad program for Win85/98 or DOS
Date: Fri, 16 Apr 1999 04:42:19 GMT
On Sat, 20 Mar 1999 22:49:28 GMT, [EMAIL PROTECTED] (R. Knauer)
wrote:
>For a real world TRNG, which is bound to leak some
>slight amount of information, the objective is to keep it from leaking
>too much. The only way I know to do that is to determine that the TRNG
>is designed correctly according to the (ideal) fundamental
>specification for crypto-grade randomness.
There's a simple (though inefficient) way to guarantee a truly random
bit sequence from a biased random bit sequence:
1) Break the biased bit sequence into pairs;
2) If the two bits in a pair are the same, discard that pair;
3) The remaining pairs are either (with equal probability) 0-1 or 1-0.
Discard the second bit from each of these pairs.
I thought everyone knew that. How come it's never mentioned in these
threads? Just curious.
(Admittedly, if your bit sequence is perfectly random, you still end
up throwing out 3/4 of the bits. I *said* it was inefficient. :-)
Earth Wolf
------------------------------
From: Tim Darling <tdarling#@#glue.umd.edu>
Subject: Possible Snr-level ugrad paper topic?
Date: Fri, 16 Apr 1999 01:59:08 -0400
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.
--
Public Key: http://www.glue.umd.edu/~tdarling/tjdarling.txt
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Can someone think this through, please. (PGP)
Date: Fri, 16 Apr 1999 05:56:47 GMT
Charles Booher wrote:
> The NSA has already computed, sorted, and indexed all 1,000,000,000
> possible PGP DF key pairs that can be computed using PGP 6
> The NSA can read your PGP email without any problem at all.
You have already posted the same notion to sci.crypt several times.
If it were true, posting once would be enough;
consequently, you are giving the impression that it must be hooey.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Adequacy of FIPS-140
Date: Fri, 16 Apr 1999 01:29:40 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> wtshaw wrote:
> >
> > In article <[EMAIL PROTECTED]>, Jim Gillogly <[EMAIL PROTECTED]> wrote:
>
> However, the question is whether the text on the Web can be considered
> to have the same amount of redundancy as the text in Shannon's experiment.
> As I indicated, the existence of search engines suggests that it has
> fewer bits per character than sensible English constructed on the fly,
> such as (superficially) this paragraph, which didn't exist until now.
> But using this paragraph as key later loses, since from a phrase or
> two it can be recovered with DejaNews.
And, it can just as easily be trivially changed, so that a derivative
could be used, and there are myrids of ways of doing that, like the
following for this sentence:
:ecnetnes siht rof gniwollof eht ekil ,taht gniod fo syaw fo sdirym era
ereht dna ,desu eb dluoc evitavired a taht os ,degnahc yllaivirt eb ylisae
sa tsuj nac ti ,dnA
>
> > Abstracting randomness is fairly easy, and there are a number of methods
> > to do it from text. It also matters what you do with the results, as keys
> > are simply used by some algorithms, and better used in more complex ways
> > by others.
>
> Those methods become part of the key, of course, since you can't tell
> the cryptanalyst what page you're looking at and what you're doing to it.
Surely you can, and still leave him without much of a clue, if the hash is
sufficiently good. It does boil down to just that, hashing to disguise the
source and produce a key that conforms to requirements of the algorithm.
>
> > Applying some simple cryptological manipulation to text could foil a
> > possible search-engine attack. A good means of distributing material on
> > the web that is not going to be searchable is to use hidden directories
> > and obscure file names.
>
> And those become part of the secret key also. In the end you may have
> more secret bits in the key you're constructing (page and algorithm)
> than you're extracting from the page itself!
Not necessarily, as a short encrypted message could give sufficient
information to locate and construct some wonderfully long key that would
especially appeal to those who relish in that sort of thing.
>
> > Then, there is the news: Given who knows how many messages out there, you
> > could easily mix and mingle randomness from a selected few of them. One
> > problem with the news is that service may be rather spotty, not all
> > messages going to all servers.
>
> And the selection and mixing algorithms constitute the key; the passage
> itself doesn't contribute any more than the pointers to it.
>
That is true, and, important, that instructions for locating text can
leverage tremendous amounts of information, making their relative
resulting key content expressly high. As applies to urls, a transitory
content could boost the usefulness of them even higher. The possibilities
for keys are rather endless, not something easily harnessed or fully
monitored, especially when those dedicated to working around such things
are concerned.
Visions of keeping everything on the internet nice and tidy under some
sort of thumb or closely defined umbrella are simply outstripped by the
living nature of the thing. Cerf gave at CFP`99 a negative reply as to
whether anyone really could define what the internet was anymore.
--
Too much of a good thing can be much worse than none.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Adequacy of FIPS-140
Date: Fri, 16 Apr 1999 01:41:58 -0600
In article <7f55dh$d89$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Patrick Juola) wrote:
>
> Of course. And chance are he wouldn't be able to use AltaVista; instead
> he would want to write his own custom SpiderBot that would index
> documents by some cryptographic property instead of by keyword.
>
> Not a difficult task; I'd feel comfortable assigning one of my undergraduates
> to index the Web according to a particular hash scheme.
>
See, we are down to hashes. If you are really comfortable with this sort
of thing and serious enough to prove so, it would be simple enough to set
it up on this end.
Of course, I would get to choose the hashing technique which I would
explain before hand. I would figure that the text used would come from
some appropriate corner of the web and/or news, just for the pure meanness
and fun that might be involved in the choice(s).
It would be another case of whether something easily done is practical to
attack.
--
Too much of a good thing can be much worse than none.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Adequacy of FIPS-140
Date: Fri, 16 Apr 1999 07:36:38 GMT
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).
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Adequacy of FIPS-140
Date: Fri, 16 Apr 1999 00:56:18 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> On Thu, 15 Apr 1999 02:21:15 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
>
> >I think you missed the point of my comment....
>
> Very possibly. What was it?
>
Consider it encrypted...now, analyze.
--
Too much of a good thing can be much worse than none.
------------------------------
Crossposted-To: talk.politics.guns
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Comments to DOJ re NICS
Date: Fri, 16 Apr 1999 07:36:51 GMT
In article <7f6mio$1fjf$[EMAIL PROTECTED]>, John Payson <[EMAIL PROTECTED]> wrote:
>Basically, the goal here is to allow for the following:...
>
> [3] The info in [2], when coupled with the information in [1], is full
> and complete proof that the FFL supplied the information in [1] to
> NICS, **INDEPENDENT OF ANY RECORDS NICS MIGHT KEEP OF THE TRANS-
> ACTION**.
Aha, I didn't quite understand this. Also, I thought part of the goal
was to maintain the fiction that NICS doesn't really keep the data
around, so the only way they check the registrations is by visiting FFL's.
Is there some reason why this can't all be done with computers and
modems, e.g. the FFL connects to a secure NICS web page in order to
register a gun? Then NICS sends back a certificate containing the
registration info and a public key digital signature. The certificate
can be kept in a disk file, or printed for safekeeping in a way that
can be scanned accurately. No need for cd-roms etc.
The gun dealer wouldn't even need a real computer; s/he could use
something like a WebTV. The certificate could be encrypted with the
dealer's public key and stored on one or more remote servers of the
dealer's choice (e.g. the NRA might run a server), so the dealer
doesn't have to maintain a reliably backed up hard disk and doesn't
have to trust NICS to not lose the certificate. The dealer could
download the stored certificate at any time and decrypt it with
his/her private key. The server operator would not be able to read
the certificate contents, because of the encryption.
This does require the dealer to have an extra piece of equipment (the
computer or WebTV) around, and access to a phone line, but the
hardware isn't that expensive. I don't know how much it costs to
become an FFL in the first place (or pay mandatory insurance premiums,
if any) so the computer expense might be trivial by comparison.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Adequacy of FIPS-140
Date: Fri, 16 Apr 1999 01:04:16 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
>
> We've been arguing that there is no reliable metric for "approaching
> the security that might be obtained with a OTP", i.e. perfect secrecy.
>
We surely all know that determining cryptographic strength is like trying
to nail jello to the wall, but some forms of jello are more nailable than
others. In short, we get back to considering the effort and data
requirements needed to break a key in given cryptosystems. Clearly some
are easier broken than others; the ones that appear stronger approach OTP
security more than those that don't.
As the OTP is at an infinity position, plaintext being zero, there is lots
of room on the continuum to order multitudes of other algorithms.
--
Too much of a good thing can be much worse than none.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES Round 1 deadline: 15th April 1999
Date: Fri, 16 Apr 1999 02:04:11 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Matthias Bruestle) wrote:
> wtshaw ([EMAIL PROTECTED]) wrote:
> > In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (John Savard) wrote:
> > > David Crick <[EMAIL PROTECTED]> wrote, in part:
>
> > > >Just a reminder (as if one's needed) that the deadline for comments
> > > >on Round 1 of AES is 15th April 1999.
> > >
> > > Like the Bulwer-Lytton Contest, they chose a day easy for Americans to
> > > remember...
> > >
> > It is also the date of the pre-cattlecall meeting, two years ago.
>
> What is so special about April 15th?
It's the day we in the US are mandated to get our tax returns mailed, if
not before.
--
Too much of a good thing can be much worse than none.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Adequacy of FIPS-140
Date: Fri, 16 Apr 1999 01:58:02 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> [NB: Nitpickers would point out that the exact result is (2^40)*(2^40
> -1)*(2^40 -2), since you don't want to use the same document more than
> once.]
Ah, a good assumption not to make. Anything possible is game.
> And that does not take into account the many additional combinations
> formed by different offsets into each document.
>
> Ok, let's see - (2^40)^3 use to be something like 2^120 last time I
> looked, which is somewhere in the neighbothood of 2^128. And if I
> want more than that, I just mix in more well-hashed documents. One
> hundred of them would give the astronomical value of 2^4000. That
> ought to keep people busy for a while trying out various combinations.
>
As I have said so often, text is useful source for keys. And, despite
trying to say that it is not, your figures, even if wildly off, still
indicate the same thing. It is wanted that keys are such difficult things
to make, that only good ones can be created by a selected few who know how
to do it.
Like most of the other things about simple, strong cryptography, the
methods for making keys for the multitutes are too easily defined to be
hidden. Such technology is neither high-tech, which cause vested
interests to drool, nor difficult to implement, which causes governments
to see possible control of use of those ideas utterly evaporate.
--
Too much of a good thing can be much worse than none.
------------------------------
** 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
******************************
