Cryptography-Digest Digest #651, Volume #10      Tue, 30 Nov 99 12:13:02 EST

Contents:
  Verication - Anyone? (Glenn Larsson)
  The $10,000.00 contest (SCOTT19U.ZIP_GUY)
  Re: Paradise shills?? (Tony L. Svanstrom)
  Re: VIC cipher strength? (John Savard)
  Re: Random Noise Encryption Buffs (Look Here) (John Savard)
  Re: Verication - Anyone? (Mark Carroll)
  Re: NSA should do a cryptoanalysis of AES (Bruce Schneier)
  Re: Paradise shills?? (James Felling)
  Re: AES cyphers leak information like sieves (Volker Hetzer)
  Re: brute force versus scalable repeated hashing (Benedikt Stockebrand)
  Re: Cryptological discovery, rediscovery, or fantasy? (Volker Hetzer)
  Re: Question About SHA-1 (Volker Hetzer)
  Re: A dangerous question (Jim Nelson)
  Re: Use of two separate 40 bit encryption schemes (jerome)
  Re: kremlin encrypt any good?? which algorithm?? (JPeschel)
  Re: PageSecure v2.0 - is it weak or strong ? (Michel Dalle)

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

From: Glenn Larsson <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Verication - Anyone?
Date: Tue, 30 Nov 1999 14:11:06 +0100

Hi. I'm developing a Bignum + DH implementation. I need someone
to confirm that i'm on the right track so what i'm asking for
is someone to verify this:

        (Compiler overflows at 65536^2)
        65537 ^ 9 = 
        22303807926762253812938859060411589043224577
        Mod
        976234876234812734876124246346
        =
        291762786418173483520827836081

Thankfull for answers, since i don't have access to a bignum lib
and cannot confirm it, that's why i'm developing it...Catch 22.

Regards,

Glenn
Sweden

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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: The $10,000.00 contest
Date: Tue, 30 Nov 1999 14:37:33 GMT

 As people should well know I ran a contest for over a year. It
was a black and white contest where the solution is easy to
verify. Mr BS run a contest that was not Black and White
but offered to give ten thousand dollats to whoever give him
the best crypto analysis of Two Fish during Round 1 of AES.
What ever happened to this money. Or did he did he decide
no one was worthy.Note the contest was such that the best
would win. This means of the analysis sucked if only dumb
comments where entered that there should be a winner.



David A. Scott
--

SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
                    
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm

Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm

Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm

**NOTE EMAIL address is for SPAMERS***

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

From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Crossposted-To: rec.gambling.poker
Subject: Re: Paradise shills??
Date: Tue, 30 Nov 1999 14:47:38 +0100

ParadisePoker <[EMAIL PROTECTED]> wrote:

> Our research and methodologies into shuffling and random-number generation
> are available at http://www.paradisepoker.com/shuffling.html and
> http://www.paradisepoker.com/rng.html

Hmmm... would be interesting to see what people working with
cryptography thinks about this (hence the lil x-posting).


     /Tony
-- 
     /\___/\ Who would you like to read your messages today? /\___/\
     \_@ @_/  Protect your privacy:  <http://www.pgpi.com/>  \_@ @_/
 --oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
 DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82  78A6 647F F247 9363 F1DB
 ---ôôô---ôôô-----------------------------------------------ôôô---ôôô---
    \O/   \O/  ©1999  <http://www.svanstrom.com/?ref=news>  \O/   \O/

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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: VIC cipher strength?
Date: Tue, 30 Nov 1999 13:57:15 GMT

On Mon, 29 Nov 1999 23:51:59 -0800, "r.e.s." <[EMAIL PROTECTED]>
wrote:

>While browsing in a bookstore recently, I noticed
>that in three different books the so-called "VIC"
>cipher (the pen-and-paper cipher used by Soviet
>agent Hayhaynen) was referred to as "very secure",
>"strong", and "virtually unbreakable" by today's
>standards.  John Savard's webpage also says it
>"seems highly secure".

>How can that be?

>The key-components appear to be only a 20-letter
>keyphrase, a 6-digit keynumber, and a 5-digit
>message key.  Doesn't this effectively correspond
>to a key well under 80-bits wide?

Well, it is highly secure for a pencil-and-paper cipher. Even SIGABA,
the highly-secure rotor machine that was unbroken through World War
II, effectively had - with its index rotor settings and rotor order
for the ten other rotors - a 44-bit key.

But it was impregnable against cryptanalysis, and increasing the
effective key length would take only minor changes.

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

From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.physics
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Tue, 30 Nov 1999 14:04:26 GMT

On Mon, 29 Nov 1999 18:46:17 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote:
>In article <[EMAIL PROTECTED]>,
>  "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>> Tom St Denis wrote:

>> > If I took two exact copies [leave the copying theory behind here] of
>> > an atom, and placed them in two exact same environments.  Would they
>> > not decay the same way?  If so, that's hardly random at all.

>> The simple answer is, no, two identically prepared quantum systems,
>> constrained as tightly as nature allows, need not evolve along the
>> same path.

>That's like saying each time you went back in time [the exact same
>time] you would observe a different state.  Which means a atom can
>never be in one state at any time.  Kinda like an omni-state..

The idea is that a quantum system does *not* have any structure below
the fundamental particle level. Observation of a quantum system
requires it to fall into an eigenstate of the observable involved, and
this must take place at random.

Thus, if one has a particle whose momentum and position are partly
localized, it will have a wave which looks like a pulse of a certain
frequency. But if one wants to make a more accurate observation of its
momentum, the probability of a given momentum is represented by the
square of the level at that momentum of the complex Fourier transform
of that wave.

There is nothing "inside" or "below" the wave to make one specific
momentum be the one to be found in a particular case.

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

From: Mark Carroll <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Verication - Anyone?
Date: 30 Nov 1999 14:13:35 +0000 (GMT)

In article <[EMAIL PROTECTED]>,
Glenn Larsson  <[EMAIL PROTECTED]> wrote:
(snip)
>       65537 ^ 9 = 
>       22303807926762253812938859060411589043224577
>       Mod
>       976234876234812734876124246346
>       =
>       291762786418173483520827836081
>
>Thankfull for answers, since i don't have access to a bignum lib
>and cannot confirm it, that's why i'm developing it...Catch 22.
(snip)

ohio:carroll$ bc
65537 ^ 9
22303807926762253812938859060411589043224577
22303807926762253812938859060411589043224577 % 976234876234812734876124246346
477376334740716679392684972971
quit
ohio:carroll$ 

-- Mark

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

From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Tue, 30 Nov 1999 15:06:53 GMT

On Tue, 30 Nov 1999 05:08:16 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:

>Bruce Schneier wrote:
>> >Not likely, since FOIA has an exemption for imformation classified
>> >in the interest of national security.
>> According to the various FOIA experts I've spoken with, there is some
>> precedent for denying that exemption because AES is a civilian
>> standard, and not a military one.
>
>That has nothing to do with the FIOA exemption.
>It isn't the use to which you wish to put the protected
>information that matters, it's the necessity to continue
>to protect the information for the sake of national
>security (which gets determined by NSA in this example).

Okay.  There are those with considerable experience that argue
otherwise.  I see no harm in trying.  You may be right.

Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc.  Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com

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

From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: rec.gambling.poker
Subject: Re: Paradise shills??
Date: Tue, 30 Nov 1999 09:09:29 -0600



"Tony L. Svanstrom" wrote:

> ParadisePoker <[EMAIL PROTECTED]> wrote:
>
> > Our research and methodologies into shuffling and random-number generation
> > are available at http://www.paradisepoker.com/shuffling.html and
> > http://www.paradisepoker.com/rng.html
>
> Hmmm... would be interesting to see what people working with
> cryptography thinks about this (hence the lil x-posting).

Well.  The points rasied are valid.  However, they in no way discuss the
source/algorithim for their RNG.( Just because it is 2016 bits in size does not
mean anything unless the underlying algorithim is also sound.  If that
algorithim for accumulating randomness is sound their RNG is more than
sulficient for the purposes of generating hands.The second possible reservation
I would have is that they do not reveal how the 31 bit random number used for
the shuffle is obtained from the 2016 bit seed.  If this is also a good method,
the claims made in re bias are indeed accurate.

The next question is, how much better/worse are they than the competition?
Assuming that they are using good algorithims for their RNG and 31 bit value for
the shuffle, then they are probably close to maximal randomness for shuffling.
So the best one could do is provide equivalent randomness.

Assuming that they have some inadequacy in their implementation( and this is not
an impossible -- designing and implementing random number generators properly is
HARD), then other sites algorithims may be better or worse than theirs.

As it stands this certianly sounds very good, but there is not enough data on
the table to be certian as to whether this is indeed as good as it sounds, or
merely buzzword compliant.

>
>
>      /Tony
> --
>      /\___/\ Who would you like to read your messages today? /\___/\
>      \_@ @_/  Protect your privacy:  <http://www.pgpi.com/>  \_@ @_/
>  --oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
>  DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82  78A6 647F F247 9363 F1DB
>  ---ôôô---ôôô-----------------------------------------------ôôô---ôôô---
>     \O/   \O/  ©1999  <http://www.svanstrom.com/?ref=news>  \O/   \O/


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

From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Date: Tue, 30 Nov 1999 16:04:59 +0100

Tim Tyler wrote:
> 
> Volker Hetzer <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> 
> [block size doubling ==> work required for a break doubling?]
> 
> :     If the diffusion properties of your cipher stay the same for each
> :     block size (i.e. every bit in the plaintext block affects
> :     approximately half the ciphertext bits) then the usual attacks (like
> :     differential) will require the same number of blocks
> 
> Some attacks will require a /much/ larger numbers of blocks, however.
Such as?

> 
> : The question is rather, how much blocks you need.
> : If you have dictionary attacks in mind, then you DO need to store twice
> : amount of data.
> 
> Shouldn't that figure read 2^N times as much - where N is the old block
> size, in bits?
Why?
You want to recognise a known block. So you need that block in storage.

Greetings!
Volker
-- 
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

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

From: Benedikt Stockebrand <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: brute force versus scalable repeated hashing
Date: 29 Nov 1999 21:47:15 +0100

Juergen Thumm <[EMAIL PROTECTED]> writes:

> Bill Unruh wrote:
> 
> > And is still susceptible to dictionary lookup. The enemy can simply
> > prehash all of your 8 character pass phrases, and do a lookup when he
> > gets your message. 8 characters is too little, no matter how you massage it.
> 
> good idea, let's follow this:
> 
> the attacker would have to store 36**8 == 2.82e+12 patterns,

Do you know that a dictionary attack is based on a dictionary of
common words?  Considering the whole key space is ridiculous.  My
off-the-shelf BSD /usr/share/dict/* has about 300k entries.  Even if I
allowed for uppercase, lowercase and capitalization (which you
ignore), words written forward and backward and added four bytes for
back indexing (which you omitted) that's hardly enough data to be
noticeable on a low-end 16 GB hard disk.

Do you actually expect real-world passwords to be taken from a
somewhat evenly distributed key space?  The only way to enforce this
is giving your users an assigned password, which in 98% ends up on a
post-it sticker on the monitor.

> with 16 bytes each, makes 4.51e+13 bytes,
> or a 41 Terabyte lookup table.
> today's largest machines work in the gigabyte range.

Eh?  Every average cheapo desktop PC works in the "gigabyte range".

> this may change within one or two decades,
> especially with the development of holographic storage,
> but at least today, a table-based attack still requires
> massive investment and should be limited to well-equiped
> secret services only.

A TB of disk space is available at somewhere around EUR/US$ 15-20k.
This isn't exactly big money.  Even with decent SCSI disks and a
proper RAID array it should be well below EUR 50k, but using cheapo
PCs with four 25GB IDE disks each is cheaper and more efficient for a
parallelized dictionary attack.

> to encounter this, one solution may be to create no 16-bytes
> output in the hashing loop but, for example, 128 bytes
> and combine this with the random block, to build the input
> for the final symmetric key. any comments?

The obvious solution to avoid dictionary attacks is exactly what Un*x
does since the beginning of times: Use a random salt value; preferably
from a larger value space than old-fashioned Un*x passwords do.  Say
starting at expt(2,32) and going up to expt(2,128) or so.


    Ben

-- 
Benedikt Stockebrand, Dipl. Inform.       http://www.ruhr.de/home/devnull

   Unix- und Netzwerkmanager auf             Unix and network manager
der Suche nach einer neuen Stelle.            looking for a new job.    

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

From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Cryptological discovery, rediscovery, or fantasy?
Date: Tue, 30 Nov 1999 17:05:07 +0100

CoyoteRed wrote:

> But lie detectors can be fooled and I'm sure there is a way to fool
> this also.
A variant of this is used to check the hearhig of babies.
You play them a sound and you can see on the EEG whether they hear it.
They're just barely conscious (i.e. they won't think much about the sound),
yet it is supposed to be very reliable.
>From this one could conclude that with conscious thought you won't be able
to do much about a lie detector like that.
The thing is, of course that you can always say you recognised it because you
saw "something like this on TV lately"...

Greetings!
Volker
-- 
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

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

From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Question About SHA-1
Date: Tue, 30 Nov 1999 17:06:50 +0100

dpwhite wrote:

> If anyone can assist in this definition, please email me at
> [EMAIL PROTECTED] or [EMAIL PROTECTED]
The gist is that the hashes should be indistinguishable from a simple
random mapping.
If I remember right this means:
- Given one hash, the chance of some other object having
  the same hash is 2^-160
- If you create and keep many hashes, you need 2^80 objects
  for the likelyhood of a collision to reach 50%.

Greetings!
Volker
-- 
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

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

From: Jim Nelson <[EMAIL PROTECTED]>
Subject: Re: A dangerous question
Date: Mon, 29 Nov 1999 23:13:20 -0800
Reply-To: [EMAIL PROTECTED]


Johnny Bravo wrote:
> 
> On Sun, 28 Nov 1999 21:55:55 -0800, Jim Nelson
> <[EMAIL PROTECTED]> wrote:
> 
> >The idea is that the assassin would place a "correct" guess -- he knows when
> >he's going to act, presumably -- and collect the winnings.  Thus, no contract
> >was made, no conspiracy planned, and so on.
> 
>   How is this any different from putting out a contract on someone?
> Anyone can play, and only the killer gets to collect.

Everyone participating wagers on the date so-and-so dies (or is killed). 
Everyone guessing correctly gets a share of the pot (as you, oddly, describe
below).

Saying this alone constitutes an illegal contract is like betting on the
Lakers and being arrested for fixing the game.

> The only
> difference in the paper is that people have to put in money with each
> guess to prevent massive random guessing.

That's how most wagering games work.  I guess I assumed that was understood in
my post.

> > Double-blind anonymity ensures no one knows who's collecting or who bet.
> 
>   This is where it breaks down of course.  Would you risk the rest of
> your life in prison in return for a promised payoff by a person who
> you don't know and can't find?

"Assassination Politics" relies on protocols that guarantee payment without
either party knowing the identity of the other.

>   Another problem is that the amount to be paid out would have to be
> fixed before any bets were collected.  The author suggested that the
> amount paid per guess be a fraction of the reward.

<snipped>

Most likely it would resemble a pari-mutuel system, where your earnings are
proportional to the amount you bet versus the total pot.

Again, my memory is cursory, so I might have some details wrong.

Jim Nelson


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

From: [EMAIL PROTECTED] (jerome)
Subject: Re: Use of two separate 40 bit encryption schemes
Reply-To: [EMAIL PROTECTED]
Date: Tue, 30 Nov 1999 16:09:49 GMT

On Sun, 28 Nov 1999 20:58:56 -0000, tony.pattison wrote:
>as I do not live in the land of the free, I'm not permitted to have
>more than 40 bit DES (I don't know why not, perhaps if we had it,
>we'd start asking for our colonies back ^_^). As this is pitifully
>inadequate, I'm thinking of encrypting the data in my packets (again
>40 bit encryption) before I send them out over my 40 bit DES
>encrypted lines.
>
>Would I get the equivilant of 80 bit encryption doing this, or would
>it be less (the paket headers are not being encrypted by the first
>encryption)?

as you want to super encypher which is probably forbidden, why not
use 3des or any other cyphers ?

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

From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: kremlin encrypt any good?? which algorithm??
Date: 30 Nov 1999 16:26:54 GMT

[EMAIL PROTECTED] writes:

>is kremlin encrypt safe to use
>
>wich algorithm is the secure
>
>DES, NewDES, Blowfish, CAST, IDEA, RC4, Safer SK-128

Yes, it's safe, I think, but Alexander Pukall recently found a fault in the
implementation of RC4. The program also has been reviewed by
Chris Hall, of Counterpane Systems, and the cracker Casimir.

I'd use Blowfish, CAST, or IDEA.

Joe


__________________________________________

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


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

From: [EMAIL PROTECTED] (Michel Dalle)
Crossposted-To: comp.lang.java.security
Subject: Re: PageSecure v2.0 - is it weak or strong ?
Date: Tue, 30 Nov 1999 16:32:46 GMT

In article <81us2e$[EMAIL PROTECTED]>, "Peter Lipp" <[EMAIL PROTECTED]> 
wrote:
>> Having looked at the decryption code, I am totally unable to determine
>> whether it would indeed represent a challenge for experienced
>cryptanalysts
>> or not...
>>
>> Could someone check it out and do a quick evaluation ?
>> See http://www.4cm.com/pagesecure/
>
>What does it do? If it is secure, the author should tell us how it works
>(didn't find anything on the pages directly and have no time downloading the
>code, which doesn't contain code apparently). Technically, using password
>based encryption, this should be doable in a safe way (decrypting the URL
>using a password that is, disregarding that the URL gets then transmitted in
>the clear most likely, unless you use SSL).

Indeed, the author has not put the code directly on his web-server, but you
can retrieve it the same way as David Hopwood did with version 1.0 a few
weeks ago : download the applet and look at how it works...

>From what I understood, the URL is still decrypted by using the password
but it should no longer have the encryption weakness pointed out by David 
Hopwood.

I do hope someone else will be able to find the time to check it out, to make
sure there are no more 'obvious' weaknesses in the algorithm.

Thanks,

Michel.

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


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