Cryptography-Digest Digest #816
Cryptography-Digest Digest #816, Volume #13 Tue, 6 Mar 01 08:13:01 EST
Contents:
Re: super strong crypto, phase 3 (Mok-Kong Shen)
Re: => FBI easily cracks encryption ...? (Matthew Montchalin)
Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily crack ...?)
(Mitch)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: PGP 2.6.3ia-cb (now supports CAST5 and BLOWFISH) ("Mark Livingstone")
Re: PKI and Non-repudiation practicalities ("Lyalc")
Re: Monty Hall problem (was Re: philosophical question?) (John Rickard)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: super strong crypto, phase 3
Date: Tue, 06 Mar 2001 11:26:56 +0100
John Savard wrote:
>
> Mok-Kong Shen<[EMAIL PROTECTED]> wrote, in part:
>
> >It seems that you use a block cipher of size 1024 bits and
> >a key of 1024 bits. Do I get that right?
>
> No. Although the message is divided into blocks of 1024 bits, my
> example is built around a block cipher with a 128 bit block and a 128
> bit key. The same key is used to encipher eight blocks of the message,
> one of which is a new key, before switching. So it is closely based on
> Douglas Gwyn's proposal.
Thanks. The other question of mine was whether it might not
be better to vary keys but without transmitting any new key
informations online.
M. K. Shen
--
From: Matthew Montchalin <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Tue, 6 Mar 2001 02:33:48 -0800
On Mon, 5 Mar 2001, Mxsmanic wrote:
|And even that isn't necessary. The spooks can just park a van across
|the street from your house and watch what you type on your screen.
|That would be a million times cheaper than trying to break your
|encryption the hard way.
As a matter of fact, that happened to me recently. I walked over to
the car (a van) across the street and asked them what they were doing,
and they showed me the screen that they were using. Rather brazen
of them, I guess. Of course, that doesn't prove to me it was *my*
computer they were scoping out. Could have been anybody's in the
area. And it still puzzles me what they think they are achieving
by going around telling people that happen to walk up and ask them;
it sure isn't very surreptitious. Isn't surveillance supposed to
be more effective if it is surreptitious?
--
From: Mitch <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily crack ...?)
Reply-To: Mitch <[EMAIL PROTECTED]>
Date: Tue, 06 Mar 2001 10:20:35 +
On Mon, 05 Mar 2001 07:06:34 GMT, Vince Adams enlightened us all with:
>How do you say it in the UK? Go bugger yourself wanker .
o will the gentleman banker please sample his wares
o Genesis 9:7
HTH
--
Mitch
--
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 03:45:02 -0800
"Douglas A. Gwyn" wrote:
>
> Anthony Stephen Szopa wrote:
> > How can we consider your less than considered opinion when you
> > clearly ignore the very post you are responding to: "in binary
> > append mode."
>
> In append mode you are *clearly* not overwriting existing data.
> I was trying to help you understand what you need to do to ensure
> the best shot at getting actual disk overwriting.
>
> > Secondly, the 156 sec 1GB overwrite does not pertain since he did
> > not even tell us anything about the code that was written that
> > carried out this operation.
> > Yet you seem to give his account all credibility not even knowing
> > this information.
>
> I don't need to know the details, since it was obvious from his
> post what was going on, namely caching.
>
> > And no, it wasn't the point. His exercise in futility is not the
> > point of this thread.
> > The point is whether or not Ciphile Software's OverWrite Security
> > program makes the 27 overwrites as claimed.
>
> If this thread had a recent point, it was that it is not as easy
> as you think to guarantee real overwrite of data sectors on disk.
>
> > Close but not quite. It is "r+b" What do you perceive now?
>
> Sorry, that's what I meant ("r+w" is not a
Cryptography-Digest Digest #816
Cryptography-Digest Digest #816, Volume #12 Mon, 2 Oct 00 18:13:00 EDT Contents: Re: is NIST just nuts? (David Schwartz) Re: It's Rijndael (Will Janoschka) Re: Comments on the AES winner (Tom St Denis) Re: is NIST just nuts? (Tom St Denis) Re: is NIST just nuts? (Tom St Denis) Re: Avoiding bogus encryption products: Snake Oil FAQ (David Schwartz) Re: is NIST just nuts? (Paul Rubin) Re: Question on biases in random numbers & decompression (Ray Dillinger) Re: is NIST just nuts? (Tom St Denis) Re: NIST Statistical Test Suite (David Rush) Re: Comments on the AES winner (John Myre) Re: is NIST just nuts? (Tom St Denis) Re: is NIST just nuts? (Paul Rubin) Re: Comments on the AES winner (John Myre) Re: is NIST just nuts? (SCOTT19U.ZIP_GUY) Re: What am I missing? (Sagie) Any products using Rijndael? ([EMAIL PROTECTED]) Re: Any products using Rijndael? (Tom St Denis) Re: Avoiding bogus encryption products: Snake Oil FAQ (Sagie) MyFish Cipher Update (Tom St Denis) Re: MyFish Cipher Update (Tom St Denis) Re: is NIST just nuts? (David Schwartz) Re: Avoiding bogus encryption products: Snake Oil FAQ (David Schwartz) Re: Shareware Protection Schemes (Jeffrey Williams) Re: is NIST just nuts? (Mark Carroll) From: David Schwartz <[EMAIL PROTECTED]> Subject: Re: is NIST just nuts? Date: Mon, 02 Oct 2000 13:18:24 -0700 Albert Yang wrote: > It wasn't the best at anything... So no Tom, twofish shouldn't have > won. The best algorithm is not necessarily the best at any particular single thing. For example, the car with the best power will have 12 or more cylinders. The car with the simplest design will have only one cylinder. The best car for the real world is not the 'best' in either of these categories. Engineering is a series of trade-offs. DS -- From: [EMAIL PROTECTED] (Will Janoschka) Subject: Re: It's Rijndael Date: Mon, 02 Oct 2000 19:53:33 GMT Not a flame Does someone know if the Rijndael key to encript RIJNDAELto*AES*WINNER*AES* does exist? Thought it wouls be a nice test vector. -will- on, 2 Oct 2000 14:46:09, Helger Lipmaa <[EMAIL PROTECTED]> wrote: > David Lesher wrote: > > > Now all the flaming can start, right? > > No, why? Rijndael was objectively the favorite. > > Helger > > -- From: Tom St Denis <[EMAIL PROTECTED]> Subject: Re: Comments on the AES winner Date: Mon, 02 Oct 2000 20:21:11 GMT In article <[EMAIL PROTECTED]>, JCA <[EMAIL PROTECTED]> wrote: > I understand that the original Rijndael (i.e. with 10 > rounds) seemed to be dangerously close to be broken, > in the sense that an 8 round Rijndael has already been > broken. I have been unable to find information in this > respect so I assume that the are no additional rounds > in the newly-elected AES. Goto www.counterpane.com/labs.html > As an aside, in my browser the number of possible > 128-bit key for Rijndael, as mentioned in the AES > fact sheet, appears as 3.4*101038. Can anybody see it as > it should (3.4*10^38)? 128 bit key = 2^128 possible keys... why convert it to base 10? Do you know how many 10^38 is? the number is too big to imagine... so why be inaccurate? Tom Sent via Deja.com http://www.deja.com/ Before you buy. -- From: Tom St Denis <[EMAIL PROTECTED]> Subject: Re: is NIST just nuts? Date: Mon, 02 Oct 2000 20:18:20 GMT In article <[EMAIL PROTECTED]>, Albert Yang <[EMAIL PROTECTED]> wrote: > I don't think Twofish should have won. Twofish is WAY too complex, and > complexity in crypto is like a cat in a rocking chair store.. First off Twofish is not impossible to code, there are several good sources already. > It wasn't the most secure or had the most security margain (Serpent wins > that) I didn't say it was the most secure, I said "Rijndael is not the most secure". Twofish is however, more secure then Rijndael. > It wasn't the most elegant (RC6, hands down) > > It wasn't the easiest to cryptoanalyse (Serpent, RC6, and Rijndael) Um Twofish is not that hard to analyzer either. It's structure is rather straight forward. The keyschedule is still a bit foggy for me, but the round function is simple (note: I used it in my design of MyFish). > It wasn't the fastest on software (Rijndael, RC6) I thought Twofish ran at 16.1 cycles per byte, that's 258 cycles per block which is 30 cycles slower then RC6. I think your speed claim is grossy disproportionate. > It wasn't the fastest on hardware (Serpent, Rijndael) Hardware is *not* where we will see alot uses of it. > It wasn
Cryptography-Digest Digest #816
Cryptography-Digest Digest #816, Volume #11 Fri, 19 May 00 03:13:00 EDT
Contents:
Re: sci.crypt cipher contest (Boris Kazak)
Re: Chosen plaintext attack, isn't it absurd? (Boris Kazak)
Re: random.org? (Benjamin Goldberg)
Re: random.org? ("Steve and Darla Wells")
Re: random.org? ("Steve and Darla Wells")
Re: NSA hardware evaluation of AES finalists (Kenneth Almquist)
Re: Unbreakable encryption. (wtshaw)
Re: Unbreakable encryption. (wtshaw)
Re: AES final comment deadline is May 15 (Kenneth Almquist)
Re: Unbreakable encryption. (wtshaw)
Re: Unbreakable encryption. (wtshaw)
Re: Base Encryption: Revolutionary Cypher (wtshaw)
Re: Base Encryption: Revolutionary Cypher (wtshaw)
what is the status finite automata base cryptosystems? (Christopher Pollett)
Re: Matching substrings in a signature (Paul Rubin)
Re: Matching substrings in a signature (Anders Thulin)
Re: Interpretation of Hitachi patent claims (Richard Heathfield)
Re: AES final comment deadline is May 15 (Volker Hetzer)
Re: Matching substrings in a signature (Anders Thulin)
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: sci.crypt cipher contest
Date: Fri, 19 May 2000 02:12:19 GMT
[EMAIL PROTECTED] wrote:
>
> Is publishing a cipher on the web (including source code) an equivalent
> of exporting it? Is the website accessible from outside the U.S.?
>
> Joseph Poe
=
AFAIK, restrictions apply specifically in case of "exporting",
which means that crypto software in question must be considered a
commercial entity.
The ciphers at the crypto-contest Web site are by definition placed
into public domain, thus they are non-commercial.
Or at least I hope so.BNK
--
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Chosen plaintext attack, isn't it absurd?
Date: Fri, 19 May 2000 02:41:51 GMT
Tim Tyler wrote:
> I suspect the original question was mis-phrased. *Nothing* is normally
> intended to stop the attacker finding out what the decryption machinery
> is. Commonly little attempt is made to conceal that - since sufficient
> security should reside in the key alone - and the attacker is assumed to
> know about the machinery in security analyses.
>
> In such attacks, the cryptographer aims primarily to prevent recovery of
> the key - or at least access to other plaintest encrypted with the same
> key - where plaintexts are partly under the control of opponents.
> --
> __ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
> |im |yler The Mandala Centre http://mandala.co.uk/ Goodbye cool world.
However, crypto professionals are now considering some additional
class
of attacks which they call "distinguishing attacks". These have as a
goal
just to determine what kind of algorithm was used in order to encrypt a
particular ciphertext. The attack is deemed successful, if the name of
the
algorithm can be established - DES or BLOWFISH or CAST or whatever.
In many cases these attacks no not lead to key or plaintext recovery,
but still experts think that a really strong cipher should resist them.
I recently submitted 2 ciphers to the sci.crypt contest at
<http://www.wizard.net/~echo/crypto-contest.html> ,
(see LETSIEF2 and MMBOOZE) but Dave Wagner found "distinguishing"
differential attacks against both(!!). Now I am considering repairs
and resubmission.
Doesn't matter that these attacks cannot recover key or plaintext...
Best wishes BNK
--
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: random.org?
Date: Fri, 19 May 2000 04:29:00 GMT
Steve and Darla Wells wrote:
[snip]
> > You may take a look at http://fourmilab.ch/hotbits/
> >
> Random.org's solution is to take a commercial quality radio (i.e. not great
> signal, not low noise) tune it to a frequency where there is no station
> (they hope it stays that way) and capture noise. The simple coin-flip
> corrector scheme, although doing a great job at fixing the bias, tends to
> leave residual correlations.
>
> Fourmilab.ch's solution is just a receiver on a much greater frequency!
> Does anyone know what additional post processing they do to either whiten
> the data or improve the actual entropy?
>
[snip]
What do you mean "a receiver on a much greater frequency?" Hotbits
works
by putting a radiation detector next to a radiation source, and
measuring
intervals between ticks... How is this similar to looking at the low
order
bits of atmospheric radio frequency noise?
--
From: "Steve and Darla Wells&
Cryptography-Digest Digest #816
Cryptography-Digest Digest #816, Volume #10 Fri, 31 Dec 99 17:13:01 EST
Contents:
Re: Attacks on a PKI (Greg)
Re: File format for CipheSaber-2? (Guy Macon)
Re: File format for CipheSaber-2? (Guy Macon)
Re: File format for CipheSaber-2? (Guy Macon)
Re: DECRYPTION Urgent! (Lonie M. Kray)
Re: Cryptanalysis (Lonie M. Kray)
Re: Encryption: Do Not Be Complacent (Anthony Stephen Szopa)
Re: The Cipher Challenge from the Code Book (wtshaw)
Re: DECRYPTION Urgent! (Bill Unruh)
Re: letter-frequency software (Bill Unruh)
meet-in-the-middle attack for triple DES ("P. Daniel Suberviola, II")
Re: The Cipher Challenge from the Code Book (Bill Unruh)
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Attacks on a PKI
Date: Fri, 31 Dec 1999 17:19:00 GMT
> > > Even if your PKI is just a matter of
> > > storing the public keys in a personal database,
> >
> > Then it is not PKI, but a personal database of keys.
>
> But it *is* a *fundamental* part of PKI: someones certificate, along
> with their public key and signature from a CA is stored on a central
> database (which, in theory, is accessible to anyone wanting to do
> business with you)
Perhaps we are refering to two different things. I mean the
local database on a PC. If that is what you are refering to,
then I have to ask, what about stale certificates? There
is a reason why the certificates become invalid, most usually
because they are not trustworthy.
> > > The next step is to do this indirectly, and to delegate
> > > this certification authority to someone else's key.
> >
> > That is where the whole thing falls apart. Now you go
> > from trusting your private key to a person you have never
> > met who could be bribed, intimidated (yes, even by the government),
> > or criminally inclined. I would prefer to trust only my
> > private key.
>
> That still doesn't solve the problem of authentication:
> How do you know you are doing business with Mr X? This is
> where you take the word of the CA who sign Mr X's certificate.
> Of course, the CA an Mr. X could both be adversaries.
I concur.
> > > This has the advantages that a much larger number of
> > > people's keys can be certified, as the certification
> > > authority can specialize in this task.
> >
> > This is no advantage at all- it is just an illusion.
>
> This *is* an advantage: The CA can specialise in certifying keys. This
> is the essence of a PKI -- the CA is a "trusted" party, thereby giving
> comfort to the authenticity of people's keys.
>
> The illusion is that this is secure - there are many attacks, and this
> leads back to my original post.
That is what I meant. The whole PKI is an illusion in principle.
> > > The disadvantage is that you now must trust this other entity
> >
> > You just proved my point in the line above. Trusting any
> > other person violates the whole concept of a private key.
> >
> Why the private key? Please explain.
Using a private key does not require you trust anyone but
yourself. The trust requirements of PKI violate that principle.
Using a private/public key strategy, PKI requires that you
go from trusting only yourself to trusting an unknown individual.
Why would you do that for?
> > > so there is nothing particularly revolutionary in extending
> > > such trust to a key infrastructure.
> >
> > Except it is being pushed by financial institutions.
>
> Yes - it appears to be the latest IT bandwagon that seems destined to
> go off the cliff.
It is sick, IMHO.
> > > As for the comments that the effort to maintain PKI security is as
> > > great as keeping shared secret keys, the difference is
> >
> > The difference is that it is an illusion and has no value.
> >
> the security of a PKI is as strong as the weakest link. At the end of
> the day, you must trust that the person you are doing business with is
> genuine. This trust can be violated through the many flaws in PKI.
I disagree. The security of PKI is weak due to its lack of a
complete protocol definition. For example, the concept of a
certificate being validated by another certificate in a pyramid
of certificates, with the top being undisputed, but no way to
define within the PKI protocol how to make such a top level
certificate 100% undisputed leaves PKI useless. PKI is a good
idea that has not been finished yet. It has holes in that
those with monetary interests are willing to gloss over today
at our expense.
> > > But in general, modification attacks tend to be more
> > > expensive than access attacks, and PKC gives you much
> > > more
Cryptography-Digest Digest #816
Cryptography-Digest Digest #816, Volume #9Thu, 1 Jul 99 15:13:03 EDT
Contents:
Re: trapdoor one way functions ([EMAIL PROTECTED])
Re: "Silk to Cyanide" (Jim Gillogly)
Re: Quantum Computers (Mok-Kong Shen)
Re: The One-Time Pad Paradox ("Robert C. Paulsen, Jr.")
Re: Quantum Computers (Mok-Kong Shen)
Re: Quantum Computers ("Douglas A. Gwyn")
Re: Kryptos article (Jerry Coffin)
Re: two questions ("dlk")
Re: trapdoor one way functions ([EMAIL PROTECTED])
Re: Quantum Computers (Mok-Kong Shen)
Re: The One-Time Pad Paradox ("Douglas A. Gwyn")
Re: "Silk to Cyanide" (Jim Gillogly)
Re: Quantum Computers ("Douglas A. Gwyn")
Re: Can Anyone Help Me Crack A Simple Code? (Medical Electronics Lab)
From: [EMAIL PROTECTED]
Subject: Re: trapdoor one way functions
Date: Thu, 01 Jul 1999 16:12:53 GMT
Nicol So wrote:
> No. We don't know if one-way functions exist because... we simply
> don't. Knowing whether one-way functions exist, either in the
> affirmative or in the negative, would settle the P =? NP question, and
> it would be such a big news that even people who are only casually
> interested in the computer science would notice.
I don't think that's entirely right. Obviously if one-way
functions exist, then P!=NP. I don't think anyone has shown
that the non-existance of one-way functions would imply P=NP.
Thus knowing wether one-way functions exist is not known to
settle P ?= NP.
Anyone know different?
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
--
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: "Silk to Cyanide"
Date: Thu, 01 Jul 1999 10:19:46 -0700
Neil wrote:
> I am reading Leo Marks boob "Silk to Cyanide" in in a early chapter (4
> I think) he gives an example of colving a transposition cipher. I
> used the transposition key he provided as the answer and can't get the
> correct codetext when I try to encrypt the original plaintext.
>
> Can anyone help this newbie and tell me what I might be doing
> incorrectly??
I assume you're looking at the message in Chapter 5, where he's
demonstrating key recovery to Col. Ozanne.
Ciphertext of first of two messages given in depth:
CNAER SSNGE CONNR OSEEE ISOAO LNGCE R ETDLS ZELTH SSNAV ANTEM
Key shown:
1 16 17 23 11 13 19 9 22 4 21 14 10 12 24 2 20 6 5 7 3 26 25 15 8 27 18
Plaintext of first message:
C O L O N E L O Z E A N N E S S I G N A L S A R E T H
E N E R V E C E N T R E S O F S O E E N D M E S S A G
E
A common way to get mixed up is to use the dual of the actual
transposition key. However, in this case the first column is
the same in either case, and the ciphertext must start CEE;
the actual ciphertext given starts CNA.
If the key were one longer, the CN would line up, but it
doesn't also work for the second message in depth. I think
we need to do the actual key recovery ourselves to see what
it should have been.
Either another key was used to encrypt it, or no key at all.
I'm guessing this was part of Marks' process of twitting
the good Colonel: he knew by this time Ozanne's eyes
would have glazed over and he would be looking for his exit
strategy from the tutorial, and would have taken Marks' word
for anything he cared to utter. This key translates to
ALLTHINGSBRIGHTANDBEAUTIFUL. I suspect we'd have better
luck comparing it to one of the rude verses composed by the
Coders of Grendon.
I'm finding the "Between Silk and Cyanide: A Codemaker's War"
enlightening and entertaining, by the way.
--
Jim Gillogly
8 Afterlithe S.R. 1999, 16:27
12.19.6.5.16, 7 Cib 4 Tzec, Eighth Lord of Night
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Quantum Computers
Date: Thu, 01 Jul 1999 19:08:37 +0200
Douglas A. Gwyn wrote:
>
> Mok-Kong Shen wrote:
> > ... We can have the concept of infinity and work
> > with it in theory, but any number that one actually operates upon
> > must be finite, even if it can be extremely large.
>
> That's certainly not true, as witnessed by the fact that Cantor
> did work with infinities. In fact a lot of us work with infinities.
> There is even a (finite) representation for some kinds of infinity
> in most floating-point processor chips made today.
If you consider Cantor's infinities to be of practical instead of
theoretical value, i.e. having real-life applications, then your
first statement is certianly true. The 'infinity' in the floating
point standard is used, if I don't err, to enable computations to
continue (instead of abort as in
Cryptography-Digest Digest #816
Cryptography-Digest Digest #816, Volume #8 Wed, 30 Dec 98 15:13:04 EST
Contents:
Re: WEAK4-EX -- Another Poorman's 56-bit Data Encryption Algorithm (long) (Mok-Kong
Shen)
Re: Decoder for Reed-Solomon codes? (Jyrki Lahtonen)
Re: New Book "The Unknowable" (John Savard)
Secure Credit Card Transactions (Benzbrood)
Re: Session keys in Elliptic Curve (liminal)
Re: Secure Credit Card Transactions ("Steve Sampson")
Re: Session keys in Elliptic Curve (Anonymous)
Re: Security through obscurity in the smartcard world (liminal)
Re: "Encrypted Magic Folders" substitute ("Sam Simpson")
Re: biometrics (Anthony Stephen Szopa)
Re: Opinions on S/MIME ("Sam Simpson")
Re: "should have" for an encrypting filesystem ("Sam Simpson")
Re: Session keys in Elliptic Curve (Mr. Tines)
Re: Blowfish assembler (i386) help needed (Paul Rubin)
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: WEAK4-EX -- Another Poorman's 56-bit Data Encryption Algorithm (long)
Date: Wed, 30 Dec 1998 15:34:51 +0100
Sorry for a typing error in text. Corrected:
do
with probability 1/scf3:
output( input() XOR pbit(scf2) );
with probability 1 - 1/scf3:
output( pbit(1) );
od;
M. K. Shen
--
From: [EMAIL PROTECTED] (Jyrki Lahtonen)
Crossposted-To: comp.dsp,sci.math
Subject: Re: Decoder for Reed-Solomon codes?
Date: 30 Dec 1998 06:57:36 GMT
You probably also need to find a primitive
>element modulo 929. This shouldn't be too hard - I will come back to
>this later.
If I didn't make any typos when plugging the numbers into Mathematica,
3 (or its residue class, if you want to be pedantic) is a primitive
element of GF(929), i.e. all the other non-zero elements are of the
form 3 raised to power i for a unique i in the range from 0 to 927
inclusive.
Jyrki Lahtonen, Ph.D.
Department of Mathematics,
University of Turku,
FIN-20014 Turku, Finland
Note to human e-mailers! To obtain my real e-mail address form the
string consisting of my first name, a period, my family name (names in
lower case) and an at-sign followed by utu.fi
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: New Book "The Unknowable"
Date: Wed, 30 Dec 1998 15:37:39 GMT
[EMAIL PROTECTED] wrote, in part:
>Hi folks, this is to let everyone know that I've
>just finished a new book, "The Unknowable".
>It's a prequel/sequel to my book on "The Limits
>of Mathematics". "The Unknowable" is available
>in html and in postscript at these two URL's:
>http://www.umcs.maine.edu/~chaitin/unknowable
>http://www.cs.auckland.ac.nz/CDMTCS/chaitin/unknowable
>Best wishes for 1999,
Ah. I read about you in Rudy Rucker's "Mind Tools".
His description of your famous proof was somewhat ambiguous.
Obviously, there is a simple proof that for any t, there _exist_
strings of complexity greater than t; as there are 2^(t+2) strings of
length t+2, there are insufficient strings of length t (2^(t+1)-1) to
generate them all.
What you had proved, I believe, was that for some t sufficiently
large, any finite system/machine cannot prove, for any specific
string, that that particular string has complexity greater than t.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
--
From: [EMAIL PROTECTED] (Benzbrood)
Subject: Secure Credit Card Transactions
Date: 30 Dec 1998 16:08:30 GMT
I need the info, progs, urls, or whatever I need to make a web site with secure
transactions for an online store, subscriptions, etc. Please reply.
--
From: liminal <[EMAIL PROTECTED]>
Subject: Re: Session keys in Elliptic Curve
Date: Wed, 30 Dec 1998 08:58:15 -1000
> Hello again.
>
> Big thanks to both Mr. Tines and Harpy-34 for their
> graceful handing of information regarding elliptic
> curve cryptography.
My pleasure.
> Now, as the session key-thing is effectively settled
> (as far as matters anyway,) now I'd like to ask a bit
> about the private key in elliptic curve, and generation
> of private/public keypair.
>
> What would be the process of generating a 160 bit
> elliptic curve key?
This is so difficult that I would not even consider attempting to explain
the method. But I will outline the hurdles you would fail to surmount.
First, chose an elliptic curve which satisfies the MOV condition and
which has enough Points on it so that a search is intractible for your
adversaries. For a discussion of these tasks see:
http://ds.dial.pipex.com/george.barwood/ec_faq.txt
which George Barwood has generously posted on the WWWeb.
>Public/private keylengths?
All numbers are less than 170 bits.
