Cryptography-Digest Digest #452, Volume #9       Thu, 22 Apr 99 22:13:04 EDT

Contents:
  Re: Thought question: why do public ciphers use only simple ops like shift and XOR? 
(SCOTT19U.ZIP_GUY)
  Re: Block Cipher Question (John Savard)
  Re: PGP=NSA (what is it about crypto?) ([EMAIL PROTECTED])
  Re: On Being Earnest (John Savard)
  Re: CryptoKong (Medical Electronics Lab)
  Re: SNAKE#14... (Thomas Wu)
  choosing g in DH (Phil Howard)
  Re: choosing g in DH (Piso Mojado)
  Paper on (in)security of passwords (Florian Erhard)
  Common Passowrds (Nathan Christiansen)
  Re: choosing g in DH (D. J. Bernstein)
  Re: PGP=NSA (what is it about crypto?) ([EMAIL PROTECTED])
  Re: 128 bit DES ("Steven Alexander")
  On Differential and Linear Analysis (going formal) ([EMAIL PROTECTED])
  Re: choosing g in DH (Michael J. Fromberger)
  Cryptanalysis (Casey Sybrandy)

----------------------------------------------------------------------------

From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: Thought question: why do public ciphers use only simple ops like shift 
and XOR?
Date: Thu, 22 Apr 1999 19:51:14 GMT

In article <7fn9el$e2v$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] wrote:
>...
>     Personally, I have often expressed the opinion that the biggest
>     security risk in cipher design is the possible discovery of a
>     catastrophic attack method against cipher designs considered
>     strong today. A catastrophic attack would be an attack that can be
>     used in _practice_ to uncover the secret key based on only a
>     handful of known plaintexts. If this should happen in the future
>     and work against a standard cipher, the repercussions could be
>     worse than the Y2K error.
>
>     Now I have argued that a possible defense against unknown attacks
>     are ciphers that have as little internal structure as possible. My
>     reasoning is that a catastrophic attack will probably take
>     advantage of some characteristic or weakness of the cipher's
>     structure. If a cipher has little structure then it will be less
>     likely to have that weakness. Now, what you are saying is I think
>     more radical: you are saying that current cipher design
>     methodology based on analysis against known attacks not only fails
>     to strengthen the new ciphers against unknown attacks but actually
>     makes them weaker.
>
>     Super-encipherment, where several distinct ciphers, preferably
>     with distinct design philosophies, are combined in series is
>     another albeit slower defense against unknown attacks. The
>     reasoning is that it is unlikely that an attack would be powerful
>     enough to penetrate all different key-schedule methods and layers
>     of rounds. There is another advantage here: there may exist a
>     "General Cryptanalytic Theory" that can be used to analyze and
>     catastrophically break _any_ cipher whose workload is bellow some
>     limit, i.e. any cipher that is fast enough. A slow and complex
>     "Super-Cipher" would hopefully exceed this limit. I wonder if
>     concurrently to the fast AES, we shouldn't have a standard
>     Superencipherment algorithm scalable in speed. Really important
>     security could then be done at orders of magnitude less speed than
>     the AES, possibly at a few kilobytes per second on a PC.
>

  Your feelings are correct except for one small point. The AES contest
is not about having secure encryption. The NSA would never allow a good
common method to be blessed by the government for general use.
 So that is why you will never see a blessed super cipher method made
of completely different methods. Unless each method added information
at each pass so that they could be broken independitly.

  If you put such a package together be sure to add scott16u or
scott19u in it. In each a have a mode where the file size out
matchs the file size in. This should be a requirement for your
approach to a super-cipher. If the method cahnges the file length
it is to hard to check for NSA approved added info to the methods
so that it could be broken.
  I also think even my hate mongers would agree my methods are very
different than the so called blessed methods.


David A. Scott
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Block Cipher Question
Date: Thu, 22 Apr 1999 21:01:58 GMT

[EMAIL PROTECTED] wrote, in part:

>I've been looking into devices that fully encrypt computer hard drives. 
>Since the IDE bus is only 16-bits wide, I was wondering if there was a block
>cipher algorithm that could be implemented using a 16-bit block size.  If
>there's not, and the device buffers the data is buffered during transmission,
>then this would generate a degredation in performance.

Well, the "G Permutation" in Skipjack (it was declassified a while back)
consists of a miniature four-round Feistel cipher using a single 256-byte
S-box as its f-function. That is an example of a block cipher with a 16-bit
block.

But by itself, it isn't a very secure cipher.

You could use a stream cipher, or you could use a block cipher with a
larger block size to generate bits that are XORed with your data bits.

Many combinations are possible. You could, for a high degree of security,
do something like this:

(address of 16-bit chunk) -> (large block cipher) -> key,

encrypted data -> (small block cipher) -> output

that is, use a block cipher with a larger block size to produce bits,
varying with each 16-bit position on the disk, used as the subkeys for a
tiny block cipher of the kind you mention.

But that involves knowing where the data came from on the disk, so you
couldn't just clip it on the IDE bus.

John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: PGP=NSA (what is it about crypto?)
Date: 22 Apr 1999 21:05:35 GMT
Reply-To: [EMAIL PROTECTED]

Medical Electronics Lab <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] wrote:
>> 
>> Who let this flake in here?
>> 
>> And what is the deal with cryptography attracting these ranting lunatics?
>
>The net is free for anyone to use.  Every newsgroup has it's
>lunatics, just like every town has its drunks, flakes and 
>know-it-alls.  Rather than get mad the best approach is pity.
>Toss them a quarter every now and then.  If they pick it up,
>you know you're dealing with something smarter than a dog.
>If they know they can buy a clue, you've found someone smarter
>than a monkey.  Some are trainable, some aren't.
>
>Chill out man, stress shortens your life.  I find laughter
>a much simpler route.

Hmmmm?  I'm not sure what I said to make you think I was mad or stressed.

Bored enough to tilt at a windmill, maybe...

-- 
Lamont Granquist ([EMAIL PROTECTED])
ICBM: 47 39'23"N 122 18'19"W

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: On Being Earnest
Date: Thu, 22 Apr 1999 21:17:46 GMT

[EMAIL PROTECTED] (Mr. Alen Yoki) wrote, in part:

>Everything Bruce Schneier said in that article makes perfect sense to me.
>Cryptographic algorithms are sort of like fine wines, in that they have to
>age a long time before they become useful. Of course the article will be
>literally "controversial" in that eager amateur cryptographers will be in
>denial, but it's not "controversial" in the sports commentator's sense; the
>ref made a good call here.

I agree with most of it. Of course it makes sense to use a cipher product
based on technology with some kind of a track record, instead of a cipher
no one has heard of. Especially when there's so much stuff of uncertain
merit out there.

If someone has a new cipher design, rushing to sell it to people, instead
of putting it out there for competent people to look at is irresponsible,
and it's unlikely that some company with a secret cipher design is going to
have something better than all the designs that have recieved scrutiny.

I think, though, that it is possible to make "new" ciphers that aren't
really new, to overdesign a cipher so that it is going to be secure, but at
the cost of wasting cycles, and to use a new cipher in conjunction with an
old cipher in such a way that the security of the old cipher at least won't
be compromised, even if we can't be certain it will be augmented.

And the only really "old" cipher is DES, which isn't entirely satisfactory.

Also, there is the issue that if the cipher recieving the most intense
scrutiny does have a weakness after all, it might be discovered after
you've used it; intense scrutiny does have its minuses too.

Falling for snake-oil is not the alternative I recommend. But I do think
that we need to broaden our approach a little bit to obtain suitably strong
ciphers. One problem is that, due to computers constantly improving, older
designs tend not to have large enough keys, for example. If we can't safely
use anything that's not out of date, we're in trouble.

John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html

------------------------------

From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: CryptoKong
Date: Thu, 22 Apr 1999 12:55:21 -0500

Riky Amelon wrote:
> I found it with a search engine. For the other folks on sci.crypt, it's
> "Crypto Kong", and the URL is http://www.jim.com/jamesd/Kong/Kong.htm
> The author says that it uses "elliptic curve encryption" and the source
> code is available. I'd say it's worth a look at the very least.

>From that URL and into a page:
KongTools.dll.

   An OLE extension to visual basic, providing elliptic
         curve cryptographic operations, true random
        numbers, and Arc4 symmetric key encryption

This was written for my own purposes. I wrote it because visual basic is the 
by far the fastest way of creating a certain kind
of program with a reasonably acceptable user interface. However I believe it 
will be generally useful to anyone who wishes to
create a cryptographic program that manages a database, or who merely wants 
to get a cryptographic program with an
attractive user interface up quickly. 

This code is based largely on the public domain code of George Barwood, Paulo 
S.L.M. Barreto and Steve Reid , as
documented in each source file. 

Download KongTools source code (requires Visual C++ 5.0 to compile) 
===========================

the Basic crypto looks ok, you'll have to check it's security
aspects by digging into the code a bit deeper.  All this sits under
visual basic, so I don't know anything about the security of that.
Since the source is available, it's several steps ahead of most
snake oil!

Patience, persistence, truth,
Dr. mike

------------------------------

From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: SNAKE#14...
Date: 22 Apr 1999 14:36:38 -0700

Peter Gunn <[EMAIL PROTECTED]> writes:
> Thomas Wu wrote:
> >
> > Could you at least spend a little time analyzing your protocols
> > before posting them?  Of the fourteen SNAKEs you've posted, at
> > least ten of them have all been broken by basically the same
> > attack.  I hope your client/employer doesn't have DejaNews...
> 
> Careful :-)
> 
> That could easily be misread as a very arrogant and
> presumtuous insinuation that you are in no position to
> make, but I'm sure you mean you hope my employer doesnt
> think I'm wasting my time at work investigating encrypted
> key exchanges when I should be doing something productive?
> As you'll see from the time of posting its nearly all
> eventing/weekend stuff, and it is a purely academic
> pursuit.

I believe my comment was well-justified and meant in a friendly
context.  I wouldn't have said what I had if your various SNAKEs
had been each more advanced than the previous one, evolving and
becoming resistant to fewer attacks as the series progressed.
But instead, many of them, including the latest few, were all
susceptible to *exactly the same* attack.  Since each SNAKE
only took about a day or two, I got the impression (correct me
if I'm wrong) that you just tweaked a few things without really
spending the time to analyze the result.  This has nothing to do
with how experienced you are with protocol design - it's just a
matter of how much time you were willing to spend thinking about
your design.  BTW, have you read the relevant papers on password
protocol design?  They explain all these attacks in much more
detail than you're likely to find here.

If you read some past sci.crypt threads, you'll find that some
of the exchanges of this nature were far less pleasant, with
the phrase "wasting our time" being bandied about.  I don't feel
that way about what you're doing, certainly, but there might be
others who disagree.

> I'm sure you'll find that the issue of key exchanges
> (or the maths involved) isnt as well understood by the
> general (even technically oriented) populous as its
> is by yourself, and David. In fact most folks Ive
> chatted with (albeit other laymen), including those
> interested in cryptography, either dont believe its
> possible to have a strong session with a short key,
> or the issue is of significant value compared with
> traditional symmetric or public key encryption.
> However, I think its one of the most significant
> things Ive come across in my very brief investigation
> of cryptography, but, I suppose this is a matter for
> talk.politics.crypto :-)

I'll agree with you there, many people have the invalid
knee-jerk reaction of "passwords = weak" because most
password authentication systems are incredibly weak.
I'm glad you've seen the light, so to speak.  :-)
-- 
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] (Phil Howard)
Subject: choosing g in DH
Date: Thu, 22 Apr 1999 20:27:00 GMT

Are there any references available to the mathematics required
in choosing a good, or relatively good, value for g in DH?

--
Phil Howard           KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]

------------------------------

From: Piso Mojado <[EMAIL PROTECTED]>
Subject: Re: choosing g in DH
Date: Thu, 22 Apr 1999 15:54:52 -1000

Phil Howard wrote:
> 
> Are there any references available to the mathematics required
> in choosing a good, or relatively good, value for g in DH?
> 
> --
> Phil Howard           KA9WGN
> [EMAIL PROTECTED] [EMAIL PROTECTED]

http://www.cacr.math.uwaterloo.ca/hac/

You can download chapters in .pdf format.

g can be a "generator" or not a generator. It is important that
g is chosen so that raising it to integer powers will produce
a large number of unique results. If it is a generator, g will
produce all possible integer results less than the modulus. If it
is not a generator, it should produce a large fraction of the possible
integers less than the modulus, before the sequence cycles.

------------------------------

From: Florian Erhard <[EMAIL PROTECTED]>
Subject: Paper on (in)security of passwords
Date: 22 Apr 1999 22:58:41 GMT

I'm looking for a evaluation of the security of password
used in universities or companies. I rember I once read
soemthing about x% consisting of names and y% consisting of
birtdates and so on. An url or a bibliography-entry would
help! Thank you,

Florian

------------------------------

From: Nathan Christiansen <[EMAIL PROTECTED]>
Subject: Common Passowrds
Date: Thu, 22 Apr 1999 17:22:50 -0600

This is a multi-part message in MIME format.
==============9563FCED904CEF19A7FAA8A5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I am wondering if there is an online resource that gives a list
of the most commonly used passwords.

I am not looking for a word list (I can find plenty of those).

What I am looking for is a list that contains what they use as their password.

For Example:

1. Spouse's name.
2. Spouse's name backwards.
3. Social Security Number.

etc.

I'm helping a friend in the middle of a messy court case to view some password 
protected 
Word 97 files so that they can be admitted as evidence (instead of just hearsay).

Before he spends $190 or so on a program that will guess the password, he would like 
to try to 
guess the password himself using a list like the one above.

(He has already used 2 password guessing programs without success and he would like to 
try this 
before buying the more expensive programs.)

-- 

  Nathan Christiansen
==============9563FCED904CEF19A7FAA8A5
Content-Type: text/x-vcard; charset=us-ascii;
 name="nathanc.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Nathan Christiansen
Content-Disposition: attachment;
 filename="nathanc.vcf"

begin:vcard 
n:Christiansen;Nathan
x-mozilla-html:FALSE
org:Allen Communication
version:2.1
email;internet:[EMAIL PROTECTED]
title:Multimedia Programmer
x-mozilla-cpt:;0
fn:Nathan Christiansen
end:vcard

==============9563FCED904CEF19A7FAA8A5==


------------------------------

From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: choosing g in DH
Date: 22 Apr 1999 23:52:03 GMT

Phil Howard <[EMAIL PROTECTED]> wrote:
> Are there any references available to the mathematics required
> in choosing a good, or relatively good, value for g in DH?

Any square is fine: 4, for example, or 2^32. Also make sure that your
private exponent is an even number. You can work modulo any large prime
p such that (p-1)/2 is also prime.

---Dan

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: PGP=NSA (what is it about crypto?)
Date: Fri, 23 Apr 1999 00:51:00 GMT

=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1

> The KGB did not stand the test of time. It is difficult to find
really
> evil and organized people these days.
>
> Theorically, sci.crypt is for discussions about cryptology, not a
> guerilla against the NSA. However, theory is often far from
practice.

Well I know that much.  Not to be picky, but has anyone read my brief
on extended tea ciphers?  I was just wondering.  I want to write a
more
professiional paper on it, but I am awaiting feedback.  It's in PDF
format
which I think is spiffy.

It's at
http://members.tripod.com/~tomstdenis/xtea.pdf

Thanks,
Tom

=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.0.2i

iQA/AwUBNx/CqvIPgV4W6pz7EQJWUgCeIhhIAvaRAnrBJz7wAc0TDMKnkHsAn34g
Z3ZSAhZctMM7LQmVa4xmq4nc
=rZjA
=====END PGP SIGNATURE=====

--
PGP public keys.  SPARE key is for daily work, WORK key is for
published work.  The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'.  Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'.  Try SPARE first!

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

------------------------------

From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Re: 128 bit DES
Date: Thu, 22 Apr 1999 11:46:39 -0700

Double DES is unfortunately not considered to be more secure.  Using
triple-des is considered to be equivalent to having a 112-bit key.

-steven






------------------------------

From: [EMAIL PROTECTED]
Subject: On Differential and Linear Analysis (going formal)
Date: Fri, 23 Apr 1999 01:17:24 GMT

=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1

As you may be aware I have been writing
papers on TEA and possible extensions.  I have
a paper on XTEA-n which can be found at

http://members.tripod.com/~tomstdenis/xtea.pdf

But I would like to be more formal and stating why
it's a better cipher. (then TEA).  Does anybody have
any links about those types of analysis?  Just how
they work.  I will apply it myself to the TEA and
my XTEA-n ciphers...

Thanks,
Tom
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.0.2i

iQA/AwUBNx/I6PIPgV4W6pz7EQKUiwCgovzl0Pi+wyIiv3RBeh2eAsg83UkAnj9e
oLjlCG49dS3xnoWFRbisZL0E
=UY+C
=====END PGP SIGNATURE=====

--
PGP public keys.  SPARE key is for daily work, WORK key is for
published work.  The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'.  Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'.  Try SPARE first!

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

------------------------------

From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: choosing g in DH
Date: 23 Apr 1999 01:33:49 GMT

In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (D. J. 
Bernstein) writes:

>Phil Howard <[EMAIL PROTECTED]> wrote:
>> Are there any references available to the mathematics required
>> in choosing a good, or relatively good, value for g in DH?

>Any square is fine: 4, for example, or 2^32. Also make sure that your
>private exponent is an even number. You can work modulo any large
>prime p such that (p-1)/2 is also prime.

Actually, the value of g should be chosen to be a primitive element
(also known as a "generator") modulo p.  A value g is a generator
modulo p if the smallest value x such that g^x = 1 (mod p) is (p - 1).

Choosing your prime p so that (p - 1) / 2 is also prime has two
advantages.  First, it helps to thwart a couple of methods for
increasing the efficiency of computing discrete logarithms when the
value (p - 1) has several small prime factors.  And second, it gives
you a quick way to test whether some value g is a generator.

In particular, if (p - 1) / 2 is prime, then the factors of (p - 1)
are q1 = 2 and q2 = (p - 1) / 2.  To determine if some value g is
primitive, compute:

        x1 = g^q1 (mod p)
        x2 = g^q2 (mod p)

If either or both of x1 and x2 is congruent to 1 (mod p), then g is
NOT primitive.  Otherwise, it is.

There is some discussion of these matters in Menezes's _Handbook of
Applied Cryptography_, and in Stinson's _Cryptography in Theory and
Practise_, which also discusses some of the mathematics behind
computing discrete logarithms.

Cheers,
-M

-- 
Michael J. Fromberger    Software Engineer, Thayer School of Engineering
  sting <at> linguist.dartmouth.edu   http://www.dartmouth.edu/~sting/
M4txC+TccxcnDXXeP9H3bAsgg9uJHjD7omOwTuo8Fa241tAF9uZ7vHZvenUXHkxRJ/BZzx6j
    Remove clothing if you wish to reply to this message via e-mail.

------------------------------

From: Casey Sybrandy <[EMAIL PROTECTED]>
Subject: Cryptanalysis
Date: Thu, 22 Apr 1999 21:08:01 -0400

Hello.

Does anybody know where I can find some good papers on cryptanalysis in
it's many forms?


------------------------------


** 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
******************************

Reply via email to