Cryptography-Digest Digest #361, Volume #9        Fri, 9 Apr 99 03:13:04 EDT

Contents:
  Re: True Randomness & The Law Of Large Numbers ("karl malbrain")
  Re: Wanted: Why not PKzip? (Green Adair)
  Analysis of /dev/random ([EMAIL PROTECTED])
  Re: Wanted: Why not PKzip? ([EMAIL PROTECTED])
  Re: R. Knauer : True Jerk (rosi)
  Re: True Randomness & The Law Of Large Numbers (R. Knauer)
  Re: True Randomness & The Law Of Large Numbers (R. Knauer)
  Recommendation of books? ([EMAIL PROTECTED])
  question ([EMAIL PROTECTED])
  Re: Guaranteed message authentication faster than MD5 (D. J. Bernstein)
  Re: Wanted: Why not PKzip? ("Arthur N. Klassen")
  Re: Wanted: Why not PKzip? (David A Molnar)
  KL-43 (Dan)
  KL-43? (Dan)
  Re: Live from the Second AES Conference (Jaap-Henk Hoepman)
  Re: Live from the Second AES Conference (Jaap-Henk Hoepman)
  HELP ME! ([EMAIL PROTECTED])

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

From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Thu, 8 Apr 1999 14:29:16 -0700


John Briggs <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...

> > My purpose is to generate a prevailing consensus so we can move on to
> > topics more closely related to crypto.
>
> Hint:  Devil's advocates don't generate consensus.  They disrupt it.
> Admittedly you do a fine job of disruption.

Au contraire!! The role of the advocate here is to LIQUIDATE the
RANDOMNESS!!  E.g. you DIVIDE the room into those pursuing MYSTICISM, and
those interested in the REALITY, and tell the MYSTICS to
CLEAR-THE-HELL-OUT!!  Karl M



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

From: Green Adair <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Wanted: Why not PKzip?
Date: Thu, 08 Apr 1999 16:55:36 -0400
Reply-To: [EMAIL PROTECTED]

Why would you not want to use PKZIP with a good pass_phrase?

It is available as share ware, run great on DOS

Green in New Hampshire

Milton Pomeroy wrote:
> 
> Wanted - a free DOS-based encryption program which is small, fast,
>          strong and friendly
> 
> Explanation
> 
> I want recommendations of encryption software to store small amounts of
> sensitive information (up to 30kbytes) for my own use - i.e. I encrypt it,
> and I decrypt it.  Since I plan to carry the encrypted datafile and
> encryption software on floppy disk and use it on various PCs (some of which
> may not be owned by me), I plan to use it from DOS (don't want to load it on
> PC, don't want any temporary decrypted data left on the PC's hard-disk).  The
> PCs will be running DOS, Win95/8, or WinNT.  Typically, I'd run it from the
> floppy in a DOS-Window.
> 
> The mandatory requirements therefore are:
> 
>   (1) runs from DOS (and DOS-prompt in a DOS-Window)
> 
>   (2) freeware/public domain
> 
>   (3) be accessible to someone (like me in Australia) who is outside USA
>         (no export restrictions)
> 
>   (4) works in 450kBytes or less of RAM
> 
>   (5) already compiled i.e. an EXE or COM version is available
>        (I don't want the uncertainty of my doing a poor compilation
>        resulting in a poor security implementation)
> 
>   (6) EXE or COM file must be small - less than say 80kbytes
>        (if it's large, like PGP for DOS at around 400kbytes, it takes
>        over 10sec to load from floppy-drive)
> 
>   (7) fast execution - less than say 5 seconds to load from floppy
>       and complete encryption/decryption of up to 30kBytes of data
>       on a 486-66
> 
>   (8) can run from a floppy with any temporary files being stored on the
>       floppy
> 
>   (9) strong (at least 80-bit-key strength)
> 
>  (10) user-ready incl enough documentation to be used directly without doing
>         programming, compilation etc
> 
>  (11) algorithm has some pedigree - i.e. has widespread degree of respect
>         in the crypto community
> 
>  (12) implementation (inc. compilation) should have some pedigree - i.e. has
>            widespread degree of respec
> 
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

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

From: [EMAIL PROTECTED]
Subject: Analysis of /dev/random
Date: Thu, 08 Apr 1999 17:26:40 -0500

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


Hi,

Is there any analysis of /dev/random available? I am looking at porting it
over to OS/2 (unless someone knows something already available for that
platform).

tks,

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii

Hi Jeff!! :)
- ---------------------------------------------------------------

=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.0i OS/2 for non-commercial use
Comment: Registered_User_E-Secure_v1.1b1_ES000000
Charset: cp850

wj8DBQE3DS1plHpjA6A1ypsRAp08AJ9t4PoTKo8iYLFRqK1FGg/ZcZ5XVgCaAjyG
e449stJIgNAHYoHTQmyllqs=
=Ya5b
=====END PGP SIGNATURE=====


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

From: [EMAIL PROTECTED]
Subject: Re: Wanted: Why not PKzip?
Crossposted-To: comp.security.misc
Date: 8 Apr 99 22:31:14 GMT

In sci.crypt Green Adair <[EMAIL PROTECTED]> wrote:
> Why would you not want to use PKZIP with a good pass_phrase?

Because its encryption is incredibly weak (known plaintext).

Increasing the passphrase does not help (it is hashed and three fixed
length keys are generated from it).

PKCrack can usually quickly determine the three keys FROM A KNOWN
PLAINTEXT ATTACK (which I used to decrypt the ZIPped archives on my
RECOVERY disk that came with my computer ... not a real Win9x disk but
just ZIPped archives of a preconfigured system ... no way to recover just
one file if it goes bad ... had to lose everything using the RECOVERY
disk/CD ... the first thing I did was crack those ZIP files).

Finding the passphrase (which is hashed to get the keys) is difficult, but
not necessary (once one has the keys, one can decrypt).

Known plaintext is good enough.

(e.g. On a web site: "Here is the shareware programme ... you will have to
register to get the passphrase to decrypt it... here is the README file
from the ZIPped archive" ... BOOM!)

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

From: rosi <[EMAIL PROTECTED]>
Subject: Re: R. Knauer : True Jerk
Date: Thu, 08 Apr 1999 18:51:26 -0700

Douglas A. Gwyn wrote:
> 
> hapticz wrote:
> > truth is relative.
> 
> And you're asserting that as an absolute?
> If not, it's self-defeating.

   Is it not this beautiful? Just throw Goedel into a garbage can. :)

   --- (My Signature)

P.S.
   I did not (I.E. NOT) say that a falsehood can be a truth in some
(or any) consistent system.
   Please do not hammer me. I am already hammered thinner than the
two-dimensional plain (and out of shape and non-Euclidian)! :)
   Quite right! Self-defeating and self-contradictory! Guess we can not
stop at the question of 'can-I-eat-it-and-have-it', but really need to
hammer out a complete theorem.

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

From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Fri, 09 Apr 1999 00:09:56 GMT
Reply-To: [EMAIL PROTECTED]

On 8 Apr 99 16:34:10 -0400, [EMAIL PROTECTED] (John Briggs)
wrote:

>What difference do you think it makes whether you consider the sample
>to be large or small?  The likelihood of finding 34 consecutive zero
>bits in 20,000 bits is the same whether you think of it as 20,000
>single bit strings or as one 20,000 bit string.

I was referring to the so-called "Monobit Test" of FIPS-140.

>Hint:  Devil's advocates don't generate consensus.  They disrupt it.
>Admittedly you do a fine job of disruption.

Actually that is not true, on either count. The classic Socratic
Devil's Advocate acts as a foil for the contrary position, drawing out
the prevailing consensusof the experts.

In any event, my motive is to find the prevailing consensus among real
experts about issues which seem to confound the people due to a lack
of critical thinking.

Not everything is intuitively obvious upon casual inspection or can be
calculated on the back of an envelope. If existence were that trivial
it could be explained easily.

The concept of true randomness is an example of something that is very
elusive, so elusive that it may very well be at the very heart of
being. I believe it is.

Bob Knauer

"I am making this trip to Africa because Washington is an international city, just 
like Tokyo,
Nigeria or Israel.  As mayor, I am an international symbol.  Can you deny that to 
Africa?"
- Marion Barry, Mayor of Washington DC


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

From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Fri, 09 Apr 1999 00:12:32 GMT
Reply-To: [EMAIL PROTECTED]

On Thu, 8 Apr 1999 14:29:16 -0700, "karl malbrain" <[EMAIL PROTECTED]>
wrote:

>you DIVIDE the room into those pursuing MYSTICISM, and
>those interested in the REALITY, and tell the MYSTICS to
>CLEAR-THE-HELL-OUT!!  Karl M

That's the first thing that you have said thus far that makes any real
sense at the ontological level.

Being is its own reality.

Bob Knauer

"I am making this trip to Africa because Washington is an international city, just 
like Tokyo,
Nigeria or Israel.  As mayor, I am an international symbol.  Can you deny that to 
Africa?"
- Marion Barry, Mayor of Washington DC


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

From: [EMAIL PROTECTED]
Subject: Recommendation of books?
Date: 9 Apr 1999 01:35:46 GMT

Hello, could someone recommend a few books which are thorough in discussing
all known authentication protocols, key exchange protocols, etc...

Thanks.



--
=====================================================================
www.clark.net/pub/sinecto/index.html (optimized dsp/math/image libs.)
TMS320C3x/C4x/TMS320C6x, PowerPC, Pentium, Alpha, NT/Linux/Solaris/AIX


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

From: [EMAIL PROTECTED]
Subject: question
Date: Fri, 09 Apr 1999 02:08:52 GMT

Hi,

I am new to cryptology, but I have been reading some on public key cryptology,
and I keep running across things like:

     e*d = 1 mod n

What does the mod mean?  I don't see how it could be the integer remainder
after diving one by n (this would just be one).  If someone could explain
what this notation means, I would be very much obliged.

--Nathan Davis

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

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

From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: Guaranteed message authentication faster than MD5
Date: 9 Apr 1999 04:17:13 GMT

Paul Rubin <[EMAIL PROTECTED]> wrote:
> Care to explain anything about the algorithm?!

What the code does is compute a polynomial

   s = (r^{n+1} + m[0] r^n + m[1] r^{n-1} + ... + m[n-1] r + x) mod p

at very high speed, given 32-bit chunks m[0],m[1],...,m[n-1] and big
secret integers r,x. Here p is a public prime, namely 2^127-1. See
http://pobox.com/~djb/papers/hash127.dvi for some computational details.

If you have just one message m[0],m[1],...,m[n-1] to sign, you can use s
directly as a signature of the message. It's easy to prove that an
attacker, even with infinite computer power, has a negligible chance of
correctly guessing a signature of a different message.

If you have many messages to sign, you can either

   * use the same r for each message, always use x = 0, and feed s
     through a secret 128-bit function before sending it; or

   * use the same r for each message, and generate a new x for each
     message by feeding a nonce through a secret function.

Both methods are provably safe against an opponent who can't predict the
secret function. The first method doesn't need nonces; the second method
has lower latency in some applications.

---Dan

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

From: "Arthur N. Klassen" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Wanted: Why not PKzip?
Date: Fri, 09 Apr 1999 04:43:17 GMT

[EMAIL PROTECTED] wrote:

> Because its encryption is incredibly weak (known plaintext).

I've been thinking about this one... Isn't this mainly a concern for
people trying to protect Zip-encrypted install-sets from pirates (as
spamless' example at the end of that post suggested)? or are there eight
bytes of boilerplate to be had in any zip-compressed file?

Methinks I should do some research here, but I would be willing to guess
that totally unique files not disclosed anywhere else could be "safely
enough" encrypted using Zip + passphrase. Am I out to lunch here?

cheers...ank
-- 
[EMAIL PROTECTED] | The word "mercy"'s gonna have a new meaning
<*> |  +t+ -> | |0 !! | when we are judged by the children of our slaves
PGP: **** 2047/DCDF9341:E273 AD0E F99A 8869 050B 5E92 0E47 C151 **** two
finger- *** 30DF 376C 43D0 DA74 F33F 752C 192E 3711 5E52 02BF *** prints

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

From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Wanted: Why not PKzip?
Date: 8 Apr 1999 22:00:53 GMT

In sci.crypt Green Adair <[EMAIL PROTECTED]> wrote:
> Why would you not want to use PKZIP with a good pass_phrase?

> It is available as share ware, run great on DOS

because that cipher is breakable with eight bytes (or is it ten) of 
known plaintext.   

The paper's at http://www.cs.technion.ac.il/~biham/ under papers,
and some kind soul in Germany actually coded up a cracker at one point,
although I'm not sure where it is now. 

-David 



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

From: Dan <[EMAIL PROTECTED]>
Subject: KL-43
Date: Fri, 09 Apr 1999 00:42:25 -0500

Does any one know what encryption the KL-43 uses??
Dan


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

From: Dan <[EMAIL PROTECTED]>
Subject: KL-43?
Date: Fri, 09 Apr 1999 00:28:59 -0500

Does any one know what ecryption the KL-43 uses??
Dan


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

From: Jaap-Henk Hoepman <[EMAIL PROTECTED]>
Subject: Re: Live from the Second AES Conference
Date: 09 Apr 1999 08:57:48 +0200

On Wed, 07 Apr 1999 10:07:18 -0400 rohatgi <[EMAIL PROTECTED]> writes:
> Jaap-Henk Hoepman wrote:
> 
> > I have to agree with Pankaj here, in that storing only user secrets on the card
> > is only part of the answer. One important issue he did not address, however, is
> > what happens when a smart card is stolen or lost. In that case the adversary
> > has as much time to attack the card as the user would have (if it stored
> > non-user secrets), so partial countermeasures to guard against rigged terminals
> > are really not good enough.
>
>     Good point.  Some commands like "internal authenticate" typically perform
> cryptographic operations without user intervention, and the keys used there are
> subject to attack on a stolen card attack as you have point out.  However most
> smart-card protocols require the user to enter a PIN
> before the smart-card will perform a user-level transaction and usually
> the smart-card locks after a few invalid PINs.  The user -transaction keys are PIN
> protected in most good protocols.

Actually, electronic cash cards do _not_ require you to enter a PIN when paying
with it (only acknowledging the amount by pressing yes on the terminal) - at
leats that's the case in the Netherlands. Hence all keys used in the payment
protocol can be attacked freely if the card is lost or stolen.

Secure Application Modules in the terminal are not PIN protected at all, so
these are even more vulnerable (and contain even more interesting data).

Jaap-Henk

-- 
Jaap-Henk Hoepman             |  Sure! We've eaten off the silver
Dept. of Computer Science     |  (when even food was against us)
University of Twente          |         - Nick Cave
Email: [EMAIL PROTECTED]      === WWW: www.cs.utwente.nl/~hoepman
PGP ID: 0xFEA287FF Fingerprint: 7D4C 8486 A744 E8DF DA15 93D2 33DD 0F09

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

From: Jaap-Henk Hoepman <[EMAIL PROTECTED]>
Subject: Re: Live from the Second AES Conference
Date: 09 Apr 1999 09:03:47 +0200

On 8 Apr 1999 14:13:57 GMT [EMAIL PROTECTED] (Reuben Sumner) writes:
> On 6 Apr 1999 14:02:38 GMT, Ian Goldberg <[EMAIL PROTECTED]> wrote:
> >In article <[EMAIL PROTECTED]>,
> >I usually say, "the smartcard should be able to be replaced by a PalmPilot
> >without the user then being able to compromise the system".  That is,
> >assume the user has complete access to the workings of the smartcard,
> >both data _and code_.
> 
> Smartcards just don't seem like such a good idea for most purposes anymore
> period.  Most smartcards depend on their power, clock as well as input and
> output from the card reader.  Any case where the smart card reader is not
> to be trusted causes a massive problem.  To date we have differential
> fault analysis, power analysis and timing analysis.  What's next?
> 
> Personally I think a great solution is the use of palm top computers like
> the PalmPilot always.  They have their own power, clock input and output.
> Interation should be easily manageable through the infrared port.
> Go to the store, but stuff.  Clerk rings it up on the cash register.
> You aim your handy palm pilot at the infrared port on the cash register.
> Suddenly your (trusted) palm pilot screen asks you to authorize payment
> of $19.95 to X.  You sign the cheque and your palm pilot sends back an
> echeque or some form of digital cash.  As an extra bonus the content of
> your purposes is recorded for later import into Quicken or similar program.

Yes, nice scenario. But I'd prefer one _minor_ :-) addition: that the
PalmPilot contains a smart card reader in which I insert my smart card that
contains all my secrets. That's because the Pilot itself is really a terrible
place to store secrets in once it's lost or stolen. Given DPA and other
attacks, smart cards are vulnerable, but not quite as vulnarable as a stray
PalmPilot...

But given that addition I agree that PalmPilots and the like would be great
electronic purses.

Jaap-Henk

-- 
Jaap-Henk Hoepman             |  Sure! We've eaten off the silver
Dept. of Computer Science     |  (when even food was against us)
University of Twente          |         - Nick Cave
Email: [EMAIL PROTECTED]      === WWW: www.cs.utwente.nl/~hoepman
PGP ID: 0xFEA287FF Fingerprint: 7D4C 8486 A744 E8DF DA15 93D2 33DD 0F09

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

From: [EMAIL PROTECTED]
Subject: HELP ME!
Date: Fri, 09 Apr 1999 05:47:20 GMT

So this is a question in regards to hyper-basic information theory.  Some
fellow stated (happy mr. Douglas Stinson) that H(K, P, C) = H(C|K, P) H(K,P).
I found this to be an unacceptable flying leap of logic.  If you know what
the hell I am talking about, and have helpful explanations and input... well,
then I would be your best friend expecting a response at
[EMAIL PROTECTED]

If you are really helpful, I may shotgun some beer and breakdance.  I know you
would digit.  Please help.


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

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


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