Cryptography-Digest Digest #817

2001-03-06 Thread Digestifier

Cryptography-Digest Digest #817, Volume #13   Tue, 6 Mar 01 08:13:01 EST

Contents:
  Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
  Any news on the KFB mode? (Volker Hetzer)
  Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)



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 05:03:59 -0800

Scott Fluhrer wrote:
> 
> It is written "Argue not with a fool, lest you be like him".  Here I go
> again ignoring that excellent advise...
> 
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Scott Fluhrer wrote:
> > >
> > > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > The Foolish Dozen or so in This News Group
> > > >
> > > > Read below.  It'll be just like being forced to look into a mirror.
> > > > You'll see who you all really are.  Read it an weep.
> > > >
> > > > Here is why I think Ciphile Software's OverWrite program actually
> > > > 
> > >
> > > careful with your fopen() and your fclose() functions won't help you
> there
> > > either.
> > >
> > > --
> > > poncho
> >
> >
> > "...After all, it's in control of the file system...  See,
> > logically..."
> >
> > What people fail to perceive quickly enough is that we are talking
> > to several sick minds.
> Of course, "sick minds" is being defined as "anyone with any technical
> experience that indicates that the problem might be somewhat less trivial
> than Anthony Szopa believes."
> 
> >
> [Re: OS's buffering writes]
>  > I guess what you say is true even if I am writing to the file in
> > append binary mode, I suppose?  NOT!
> I suspect you meant writing the file in update mode, but in any case, of
> course the OS (and the disk driver, and the disk controller itself) can
> buffer writes.
> 
> [Do any of you claim that any OS that you know of actually returns before
> actually writing the data to the disk]
> > "...known as Unix which as precisely this property..."
> >
> > You are slandering UNIX.
> Hardly.  You may not be aware of this, but several jobs ago, a large part of
> my job was to maintain several versions of the Unix kernal.  There was very
> little that the Unix kernel did that I was unaware of (it helped somewhat
> that, back in those days, the Unix kernel was considerably smaller).  And, I
> can swear unequivocally that those versions of the Unix kernel did have
> precisely that property.  If you disagree, may I ask after your
> qualifications as a Unix kernel hacker?
> 
> In any case, I also mentioned (in a part you snipped) that I verified
> expirementally that Linux (a Unix work-alike) did in fact have that property
> (either that, or the disk on that computer spins at 384,000 RPM).
> 
> > So, what you are saying is that everything goes on in cache and that
> > disk space is not under the operator's control.  A file can be
> > written to one place on a hard drive then read into cache.
> > Processed then written to a completely different place on the hard
> > drive.  And this process can continue I suppose until the entire
> > hard drive has been written over once and no bit locations have been
> > overwritten.
> Yes, at least in theory.  And, according to Darren New, the Atari disk OS
> has pretty much this behavior.  I'm glad to see we agree.
> 
> >
> > I would think this is not likely because of the optimization you
> > claim to be expounding.  The drive heads are already over these bit
> > locations.  To wander all over the hard drive writing to no
> > predetermined fixed hard drive bit locations would be inefficient
> > and un-optimizing.
> For one, "unlikely" != "can't happen".  The drive heads might not be "over
> these bit locations", as some other program may have forced the drive heads
> elsewhere.  An OS might decide to write the sectors where the heads happen
> to be.  I have already mentioned one case (disk compression) where
> relocating sectors is quite likely.  Darren New mentioned another.  An OS
> attempting to do on-the-fly disk optimization is a fourth conceivable
> example.
> 
> >
> > With the reliability of computers these days most operations do take
> > place successfully.  There is no reason 

Cryptography-Digest Digest #817

2000-10-02 Thread Digestifier

Cryptography-Digest Digest #817, Volume #12   Mon, 2 Oct 00 19:13:00 EDT

Contents:
  Re: is NIST just nuts? (Tom St Denis)
  Re: is NIST just nuts? (Tom St Denis)
  Re: is NIST just nuts? (Paul Rubin)
  Do not vote for those communistic policies of Al Gore  (William A. Nelson)
  Re: Choice of public exponent in RSA signatures (David Wagner)
  Re: is NIST just nuts? (Tom St Denis)
  Related Key Attack on MyFish (Tom St Denis)
  My Theory... (Cornelius Sybrandy)
  Re: It's Rijndael (lcs Mixmaster Remailer)
  Re: is NIST just nuts? (SCOTT19U.ZIP_GUY)
  Re: What am I missing? (Scott Craver)
  Key Attack on Serpent (Tom St Denis)
  Re: Shareware Protection Schemes ("musashi_x")
  Problem question (Ernest Dumenigo)
  Re: Why is TwoFish better than Blowfish? ("Douglas A. Gwyn")
  Re: Ciphers and Unicode ("Douglas A. Gwyn")
  Re: Key Attack on Serpent (Tom St Denis)
  Re: Choice of public exponent in RSA signatures (Bodo Moeller)
  Re: It's Rijndael ("Douglas A. Gwyn")
  Re: Comments on the AES winner ("Douglas A. Gwyn")



From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Mon, 02 Oct 2000 21:45:58 GMT

In article <[EMAIL PROTECTED]>,
  Paul Rubin <[EMAIL PROTECTED]> wrote:
> Tom St Denis <[EMAIL PROTECTED]> writes:
> > Well given that the requirement of a block cipher is primarily
> > security, i think the fact that Twofish is more secure makes my
> > complaint quite valid.
>
> Where is your evidence that Twofish is more secure?  Apparently NIST
> and the NSA didn't think it was more secure.

Where is their evidence?  From what we know Twofish appears much more
secure.  Of course that's not scientific, but given what we can do,
it's the best we have.

They said "Rijndael performs well on a variety of platforms" but from
what I have seen Twofish does just as well.  What is their
justification for not picking Twofish?

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 21:47:40 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> [EMAIL PROTECTED] (alex) wrote in
<8rajuk$r1h$[EMAIL PROTECTED]>:
>
> >you could email monika lewinsky, she could perhaps ask the President
for
> >that.
> >
> >
> >Tom St Denis <[EMAIL PROTECTED]> a écrit dans le message :
> >8raips$vsd$[EMAIL PROTECTED]
> >> As if that was picked... From what I understand it's not at all
close
> >> to the securest block cipher.  Will aes specify that cipher with
more
> >> rounds?  What a shame...
> >>
> >> I demand a recount!  Twofish should have won!
> >>
> >> Tom
> >>
>
> I guess Tommy still does not understand. Real security has
> little to do with the contest. I am not sure two fish is secure
> but the government has to pick a cipher the NSA could break or they
> would not allow it to be used. I just hope it modivates him to find
> a break. It is even possilble the NSA may yet want another alogorithm
> so we may magically see a break in this cipher or a weakness so that
> another one of there choice could be placed out there.

I doubt they picked Rijndael because it's ultimately insecure.  I just
would have picked a cipher that resisted the cryptanalysis so far.

For all purposses Rijndael is still secure since 10 rounds cannot be
broken.  But this parallels the arguments 30 years ago against short
keys...

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

--

From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: 02 Oct 2000 15:02:04 -0700

Tom St Denis <[EMAIL PROTECTED]> writes:
> > Is that so?  Do you have a break for Rijndael but not for Twofish?
> 
> Well I said earlier that in terms of practicallity Rijndael was not
> broken.  But in that case why not just design a fast block cipher that
> takes say 2^60 work... cuz that's stupid?

Because it would not have satisfied the AES specification.

> Square was broken because of it's structure, the same attack works on
> Rijndael with limited success (7~8 rounds).  Again the best attack
> against Twofish barely breaks half of the rounds.

A cipher is not broken unless an attack breaks all the rounds, or
looks like it can be extended from breaking only some of the rounds.

> At anyrate a block cipher is suppose to be secure, I would have enjoyed
> Serpent being picked over Twofish, but at the least Twofish.

I was also rooting for Twofish, but I don't think either one of us
is qualified to say 

Cryptography-Digest Digest #817

2000-05-19 Thread Digestifier

Cryptography-Digest Digest #817, Volume #11  Fri, 19 May 00 06:13:00 EDT

Contents:
  Probabilistic Encryption (Claudio Di Flumeri)
  Re: More on Pi and randomness ("Douglas A. Gwyn")
  Re: what is the status finite automata base cryptosystems? ("Douglas A. Gwyn")
  Re: P+1 factorization algorithm (Niclas Karlsson)
  comparison of ciphers (Lieven Trappeniers)
  Re: Probabilistic Encryption ("Douglas A. Gwyn")
  Re: comparison of ciphers (Sébastien SAUVAGE)
  Re: Probabilistic Encryption (Claudio Di Flumeri)
  Re: Crypto & UNICODE??? (Marcin Jaskolski)
  Re: Unbreakable encryption. (Mok-Kong Shen)
  Re: More on Pi and randomness (Mok-Kong Shen)
  About AES contest ("Karim A")
  Re: Matching substrings in a signature (Mok-Kong Shen)
  Re: P+1 factorization algorithm (Anders Thulin)
  Cipher Challenge Stage 5 (Sisson)
  Re: Crypto & UNICODE??? (Mark Wooding)
  Re: AES final comment deadline is May 15 ("Sam Simpson")
  Re: More on Pi and randomness ("Clive Tooth")
  Re: AES final comment deadline is May 15 (Runu Knips)
  Re: AES final comment deadline is May 15 (Scott Contini)



From: Claudio Di Flumeri <[EMAIL PROTECTED]>
Subject: Probabilistic Encryption
Date: Fri, 19 May 2000 09:08:34 +0200
Reply-To: [EMAIL PROTECTED]

Do you know where can I find an online version of the paper
"Probabilistic Encryption" by Goldwasser and Micali?

Thanks
Claudio


--

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: More on Pi and randomness
Date: Fri, 19 May 2000 07:11:26 GMT

Mike Mccarty Sr wrote:
> This is not something which can be said with our current level of
> knowledge of PI. We can make statements about the first x billion
> digits, but we cannot (as yet) make statements about PI.

Sure we can; the transcendental real number universally denoted
by the symbol pi has a great many exact properties that are
mathematically proven.

--

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: what is the status finite automata base cryptosystems?
Date: Fri, 19 May 2000 07:17:13 GMT

Christopher Pollett wrote:
> Can anyone out there tell me what the current status of finite
> automata based crypto systems?

What do you mean by that term?  Practically any cryptosystem can
be thought of as a finite-state automaton.  If you mean, cellular
automata, they don't seem to be used very much if at all, perhaps
because they seem to offer no clear advantage over better-understood
cryptosystems.

--

From: [EMAIL PROTECTED] (Niclas Karlsson)
Subject: Re: P+1 factorization algorithm
Date: 19 May 2000 10:17:47 +0300

[EMAIL PROTECTED] writes:

>In article <8g0tjt$4nv$[EMAIL PROTECTED]>,
>  Bob Silverman <[EMAIL PROTECTED]> wrote:
>> The *definitive* article to read is Peter Montgomery's
>> Speeding the Pollard and Elliptic Curve Methods of Factorization
>> Mathematics of Computation,  1987

>Thanks, I'd like to read that, but where can I get hold of a copy? Can
>it be downloaded from anywhere? Or do I have to subscribe to MoC ?

It's available electronically from Journal Storage (www.jstor.org).
Unfortunately jstor is a subscription service aimed mostly at larger
institutions like universities and such, so unless you're affiliated
with one of those you're not likely to get hold of the article from
there.

The license seems to allow only a single copy for personal use.

Nicke
-- 
"A witty saying proves nothing."
  - Voltaire (1694-1778)

--

From: Lieven Trappeniers <[EMAIL PROTECTED]>
Subject: comparison of ciphers
Date: Fri, 19 May 2000 09:03:56 +0200

Hello All,

is there any survey available that discusses the amount of security
offered by various encryption algorithms ?   How do DES and 3DES relate
to blowfish, IDEA, ... concerning intrinsic strength of the algorithm
?(and of course, what is the influence of the key size).

As a non-specialist having to implement encryption, I am looking for
information in order to differentiate between the available algorithms.

I apologize if this question has a rather high degree of FAQness.

Thanks,

Lieven.



--

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Probabilistic Encryption
Date: Fri, 19 May 2000 07:23:49 GMT

Claudio Di Flumeri wrote:
> Do you know where can I find an online version of the paper
> "Probabilistic Encryption" by Goldwasser and Micali?

It took me only a couple of minutes of Web searching to turn up
the reference: Shafi Goldwasser, and Silvio Micali "Probablilistic
Encryption," Journal of Computer 

Cryptography-Digest Digest #817

1999-12-31 Thread Digestifier

Cryptography-Digest Digest #817, Volume #10   Sat, 1 Jan 00 02:13:02 EST

Contents:
  Re: Encryption:  Do Not Be Complacent (Guy Macon)
  Re: letter-frequency software ("r.e.s.")
  Re: Cryptanalysis (Jim Reeds)
  Re: Cryptanalysis (Ornie Kamyl)
  Re: File format for CipheSaber-2? (Johnny Bravo)
  Re: File format for CipheSaber-2? (Johnny Bravo)
  Re: Prime series instead (Re: Pi) (Matthew Montchalin)
  Re: Attacks on a PKI (Greg)
  Re: Q: Cryptanalysis Shareware? (nnburk)
  Re: The Cipher Challenge from the Code Book (Sisson)
  Re: The Cipher Challenge from the Code Book (Sisson)
  Re: Are PGP primes truly verifiable? (Scott Fluhrer)
  Re: Attacks on a PKI ("Lyal Collins")



From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: alt.privacy,talk.politics.crypto,talk.politics.misc,talk.politics.drugs
Subject: Re: Encryption:  Do Not Be Complacent
Date: 31 Dec 1999 17:13:36 EST

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Anthony Stephen 
Szopa) wrote:

>> So the most secure method would be:
>>
>> Hire two Navajo Code Talkers. Have one encode your message into ciphered
>> Navajo, voice recorded into a digital file. Then encrypt the file before
>> attaching it. The receiver of the message first decrypts it, then lets
>> his own Navajo Code Talker listen to the recording and decipher the
>> message.

Good method if your attacker is the third reich, not so good if your
attacker is an NSA lab on the Arizona/New Mexico border...

I have a better language choice; teen!  Try do decode this message:

"So I'm all like, you know and then he's like totally DUH and i'm like,
you know NOT a he gets SO two weeks ago so now I'M all duh, and he
spazes like totally but still kinda tubular, you know?"

The only better choice would be cockney rhyming slang.  (guess the
encoding method that changes "fart" to "rasberry", "coat" to
"quaker", and "stairs" to "apples"...)



--

From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: letter-frequency software
Date: Fri, 31 Dec 1999 15:30:08 -0800

"Bill Unruh" <[EMAIL PROTECTED]> wrote ...
: ]r.e.s. <[EMAIL PROTECTED]> a ecrit dans le message :

[... re C program to do letter frequency analysis...]

: Actually, with a bit of work, awk will do fine for reasonable length
: text.
: If you want to preserve spaces, replace spaces by some other character
: like *. Then break up the text into one character per line.  Then use awk
: with its associative arrays.
: Eg
: cat document.txt|awk 'BEGIN{N=0} {f[$1]++}END{ for (j in f) print j, " ",
f[j]}'|sort -n +1
: cat document.txt| awk 'BEGIN {N=0} N>0{f[i" "$1]++ } {i=$1;N++}END {for( j
in f) print j," ",f[j]' |sort -n +2
: cat document.txt| awk 'BEGIN {N=0} N>1{f[j" "i" "$1]++}N>0{j=i} {i=$1}
: END {for(k in f) print k, " " , f[k]}'|sort -n +3
:  This will count the frequency of all one, two and three letter
: combinations in the text.(ducument.txt is the one with all letters one
: to a line. If you are doing a playfair, then document.txt would be the
: one with all pairs on a single line, etc.

 Which icon do I click on my Win98 desktop? 
Thanks for the info -- on behalf of the Unix users among us ;-)

--
r.e.s.
[EMAIL PROTECTED]




--

From: [EMAIL PROTECTED] (Jim Reeds)
Subject: Re: Cryptanalysis
Date: Fri, 31 Dec 1999 23:27:15 GMT

 
|> I finally have the spelling down, it's "Schneier". But I'm still not sure
|> how to pronounce it.


Two syllables, Schnei + er.  The vowel sound of the first
syllable is that of the English word 'eye', that of the second
is that of 'her'.  If you know the German pronounciation
of the name Schneider, just leave out the 'd' sound.  Or:
replace the initial consonant sound of the name Meyer or 
Meier with that of 'shake'.

-- 
Jim Reeds, AT&T Labs - Research
Shannon Laboratory, Room C229, Building 103
180 Park Avenue, Florham Park, NJ 07932-0971, USA

[EMAIL PROTECTED], phone: +1 973 360 8414, fax: +1 973 360 8178

--

From: [EMAIL PROTECTED] (Ornie Kamyl)
Subject: Re: Cryptanalysis
Date: Fri, 31 Dec 1999 23:45:55 GMT

[EMAIL PROTECTED] (Jim Reeds) wrote:

>Two syllables, Schnei + er.  The vowel sound of the first
>syllable is that of the English word 'eye', that of the second
>is that of 'her'.  If you know the German pronounciation
>of the name Schneider, just leave out the 'd' sound.  Or:
>replace the initial consonant sound of the name Meyer or 
>Meier with that of 'shake'.

Thanks! That's very different from what I expecte

Cryptography-Digest Digest #817

1999-07-01 Thread Digestifier

Cryptography-Digest Digest #817, Volume #9Thu, 1 Jul 99 17:13:03 EDT

Contents:
  Re: Secure link over Inet if ISP is compromized. (Patrick Juola)
  Re: Windows PWL Files (JPeschel)
  Re: Secure link over Inet if ISP is compromized. ("Else")
  Re: Windows PWL Files ([EMAIL PROTECTED])
  Reference Implementation of Quadibloc S
  Re: Quantum Computers (Greg Ofiesh)
  Re: Quantum Computers (Mok-Kong Shen)
  Re: Quantum Computers (Greg Ofiesh)
  Re: The One-Time Pad Paradox ("Robert C. Paulsen, Jr.")
  Re: Quantum Computers (Greg Ofiesh)
  Re: Quantum Computers (Greg Ofiesh)
  Re: Quantum Computers (Patrick Juola)
  Re: Quantum Computers (Patrick Juola)
  Re: The One-Time Pad Paradox (Patrick Juola)
  Re: The One-Time Pad Paradox ("Robert C. Paulsen, Jr.")
  Re: The One-Time Pad Paradox ("Robert C. Paulsen, Jr.")
  Re: The One-Time Pad Paradox (Patrick Juola)
  Re: Quantum Computers (Patrick Juola)
  Re: Quantum Computers ([EMAIL PROTECTED])
  Re: Infinity: was Quantum Computers ("Tony T. Warnock")



From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Secure link over Inet if ISP is compromized.
Date: 1 Jul 1999 15:01:35 -0400

In article <7lgcjq$g5r$[EMAIL PROTECTED]>, Else <[EMAIL PROTECTED]> wrote:
>
>Patrick Juola wrote in message <7lfspi$mij$[EMAIL PROTECTED]>...
>>In article <7lfi2r$38f$[EMAIL PROTECTED]>,
>>Gene Sokolov <[EMAIL PROTECTED]> wrote:
>>>What do you think is the fraction of the Net users who exchange keys
>>>"out of band", i.e. not through their ISPs?
>>
>>My PGP public key is available through a half-dozen different sources,
>>including one in print (Proc. NeMLaP-2); if the FBI decides to tamper
>
>What do you think is the fraction of people who do likewise?

Anyone who signs up with the MIT key database, for one.

Anyone who *has* ever exchanged a key with someone prior to
the discussion at hand.

Anyone who makes backups of their system(s).

-kitten

--

From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Windows PWL Files
Date: 01 Jul 1999 19:06:41 GMT

>"Andrew Whalan" <[EMAIL PROTECTED]> writes:

>Anyone know about the method used to generate PWL files, thus, the method
>that could be used to crack PWL files.

Peter Gutmann did some work on this.  I believe it was someone else, however,
who wrote the PWL cracking code called "Glide," which you'll find on my site.

Joe

__

Joe Peschel 
D.O.E. SysWorks 
http://members.aol.com/jpeschel/index.htm
__


--

From: "Else" <[EMAIL PROTECTED]>
Subject: Re: Secure link over Inet if ISP is compromized.
Date: Thu, 1 Jul 1999 22:55:56 +0400


Patrick Juola wrote in message <7lfspi$mij$[EMAIL PROTECTED]>...
>In article <7lfi2r$38f$[EMAIL PROTECTED]>,
>Gene Sokolov <[EMAIL PROTECTED]> wrote:
>>What do you think is the fraction of the Net users who exchange keys
>>"out of band", i.e. not through their ISPs?
>
>My PGP public key is available through a half-dozen different sources,
>including one in print (Proc. NeMLaP-2); if the FBI decides to tamper

What do you think is the fraction of people who do likewise?


--

From: [EMAIL PROTECTED]
Subject: Re: Windows PWL Files
Date: Thu, 01 Jul 1999 18:25:52 GMT

In article <7lfral$9ij$[EMAIL PROTECTED]>,
  "Andrew Whalan" <[EMAIL PROTECTED]> wrote:
> Oh, this might target my required audience.
>
> Anyone know about the method used to generate PWL files, thus, the
method
> that could be used to crack PWL files.

They proably use their MD4 hash code (which goes with their RC4 code)
to hash the password.

If you want to cheat a passwd protected screen saver just delete
the .PWL files...

Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

--

From: [EMAIL PROTECTED] ()
Subject: Reference Implementation of Quadibloc S
Date: 1 Jul 99 19:15:02 GMT

There is a post with this title in alt.sources.crypto, containing a BASIC
program. It is for generating test vectors.

Quadibloc S is a block cipher with a 64-bit block, very similar to the
original QUADIBLOC. The program illustrates the version with four rounds.
The intent of this is to provide a cipher "weak" enough to be subjected to
cryptanalysis.

My web page will include a description of Quadibloc S tomorrow afternoon.

Quadibloc S differs from QUADIBLOC in its original form in two important
respects.

The f-function includ

Cryptography-Digest Digest #817

1998-12-30 Thread Digestifier

Cryptography-Digest Digest #817, Volume #8   Wed, 30 Dec 98 18:13:03 EST

Contents:
  Re: New Book "The Unknowable" (R. Knauer)
  Re: Security through obscurity in the smartcard world ([EMAIL PROTECTED])
  Re: Security through obscurity in the smartcard world (John Savard)
  Why no Standard C/R Password Protocol? (John Savard)
  Re: All-or-nothing encryption idea? ([EMAIL PROTECTED])
  Re: Anybody heard of these people? ("Sam Simpson")
  First issue of Journal of Craptology (Lars Ramkilde Knudsen)
  MTP Complex Number Cipher (R. Knauer)
  Re: U.S. Spying On Friend And Foe (Jim Dunnett)
  Re: On leaving the 56-bit key length limitation ([EMAIL PROTECTED])
  Re: Free ENCRYPTION Programs (32b) (David Hamilton)



From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: New Book "The Unknowable"
Date: Wed, 30 Dec 1998 20:10:15 GMT
Reply-To: [EMAIL PROTECTED]

On Wed, 30 Dec 1998 19:16:19 GMT, [EMAIL PROTECTED] wrote:

>Correct!  (That's assuming, of course, that the formal system
>only proves true theorems, i.e., is truthful.)
>Rgds,
>GJC
>P.S.  The sufficiently large t turns out to be the complexity
>of the formal axiomatic system that is being used, plus a
>constant c that doesn't depend on the choice of the formal
>axiomatic system.

While we have you here, perhaps you might like to comment on something
I just posted in another thread on sci.crypt the other day.

But first let me point out that I have been a fan of your theories for
some time now, having first learned of them on sci.crypt over a year
ago when we had a huge discussion/debate on crypto-grade randomness
going. Since then I have read your major papers on randomness and its
relation to algorithmic complexity.

The post below was addressing the use of random numbers for the One
Time Pad cryptosystem. Here is that post with minor typos corrected:

+
 it seems that Chaitin's definition of randomness does no good for
purposes of crypto. Consider the following procedure.

Begin with a plaintext and compress it using the best compression
procedure available. Call this sequence CP for Compressed Plaintext.
The assumption is that CP is the minimal representation for the
original plaintext based on compression.

Now employ algorithmic complexity by finding the minimal algorithm
that will reproduce CP. But that algorithm is just:

print (CP)

because there is no other algorithm that can reduce CP to a smaller
size.

Therefore CP is a random ciphertext which cannot be deciphered based
on any discernable pattern, since it is "random" according to
algorithmic complexity - that is the algorthm that porduces it cannot
be made substantially smaller.

IOW whatever algorithm that is employed to reproduce the sequence must
contain the literal sequence without any reduction in size, since it
is already as small as it can get by prior compression (see Chaitin,
op. cit.). So the cryptanalyst faces an impossible task since there is
no pattern for him to use to decipher the message.

But we know better - the cipher can be broken by decompressing it.
Therefore it would seem that randomness, based on algorithmic
complexity, is not a suitable measure of crypto strength.
+

Your comments, please.

Bob Knauer

"He knows nothing and he thinks he knows everything. That points
clearly to a political career."
--George Bernard Shaw


--

From: [EMAIL PROTECTED]
Subject: Re: Security through obscurity in the smartcard world
Date: Wed, 30 Dec 1998 20:12:13 GMT

In article <76b57t$[EMAIL PROTECTED]>,
  Gary Howland <[EMAIL PROTECTED]> wrote:
> ...
> But I don't want to get into the GSM debate.  I want comment on
> the priniciple of adding security (i.e. cost and expense) using
> obscurity.  My reason for wanting debate, first on the question of
> "is security through obscurity" valid, and second on "how?", is
> because I intend to write a report on the benefits of obscurity,
> and the techniques one should use when creating proprietary
> algorithms.  So in addition to comments on the validity of the
> proprietary algorithms, I would also like comments on the best ways
> of creating such proprietary algorithms.  I am going to outline a
> few of the techniques in my paper, such as the subtle modification
> of existing algorithms, adding (better than removing) rounds,
> dangers or mixing algorithms that have weak keys etc.  Any comments
> on the design of proprietary algorithms based on tried and trusted
> algorithms would be much appreciated. (...)

Before breaking a non-trivial system, an attacker must analyze it.
Obscurity is a type of defense that makes analysis difficult.
There are basically two avenues here:

 1. Try to keep the system secret. Generally speaking this is not a
good i