Cryptography-Digest Digest #868

2001-03-11 Thread Digestifier

Cryptography-Digest Digest #868, Volume #13  Mon, 12 Mar 01 00:13:01 EST

Contents:
  Re: Text of Applied Cryptography .. do not feed the trolls 
([EMAIL PROTECTED])
  Re: The Foolish Dozen or so in This News Group (Benjamin Goldberg)
  Re: Text of Applied Cryptography .. do not feed the trolls ("Tom St Denis")
  Re: An extremely difficult (possibly original) cryptogram ("Ashish Kasturia")
  Re: Text of Applied Cryptography .. do not feed the trolls (Frodo)
  Straw man hash. (Benjamin Goldberg)
  Re: Semi-super-strong crypto? (Benjamin Goldberg)
  Re: Digital enveloppe ("Trevor L. Jackson, III")
  Re: ideas of D.Chaum about digital cash and whether tax offices are (John 
Christensen)
  Re: An extremely difficult (possibly original) cryptogram (those who know me have no 
need of my name)
  Re: Text of Applied Cryptography .. do not feed the trolls ("Tom St Denis")
  Re: RSA encryption on Windows -- C++ source code (those who know me have no need of 
my name)
  Re: [REQ] SHA-1 MD5 hashing software (those who know me have no need of my name)
  Re: = FBI easily cracks encryption ...? (SCOTT19U.ZIP_GUY)
  Re: Noninvertible encryption (SCOTT19U.ZIP_GUY)
  Re: arbitrary-precision arithmetic (Benjamin Goldberg)
  Re: = FBI easily cracks encryption ...? (Phil Zimmerman)
  RE: Anonymous web browsing (Phil Zimmerman)
  Re: Digital enveloppe ("Scott Fluhrer")



From: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Reply-To: *
Date: Mon, 12 Mar 2001 02:13:36 GMT

On Sun, 11 Mar 2001 19:52:08 -0500, "Ryan M. McConahy"
[EMAIL PROTECTED] wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Actually, I was not asking for noise. I merely wanted an address. I
knew that an electronic version was available. I am a teenager, and
do not have much money, and would prefer it in an electronic version.

Perhaps you might like this, too.
http://www.umich.edu/~umich/fm-34-40-2/

Enjoy the crypto. I hope your fascination lasts your entire life.


--

From: Benjamin Goldberg [EMAIL PROTECTED]
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Mon, 12 Mar 2001 02:18:56 GMT

Anthony Stephen Szopa wrote:
[snip]
   fclose that flushes all OS buffers associated with the stream. 
   You would think this would be enough to force a write.
 
  How many times does this need to be pounded into your head?  fclose
  flushes the C library buffers, not the OS buffers.
[snip]
  That's ignoring the hdd buffers.  The drive light goes on for a bus
  transfer of data to the drive, not for actual writing.

 I am not convinced this is so.  The documentation says specifically
 "system-allocated" buffers are flushed.

If you choose to be stupid about what fclose does, you're allowed to be.

But how do you get off even thinking of the hdd buffers as "system
allocated?"  I mean, nothing in the OS /creates/ them... they're part of
dedicated hardware, and the buffers are dedicated to that specific
purpose.  Unlike OS buffers, or C library buffers, where it's just
arbitrary blocks of memory, which could be used for anything at all,
until the Os or user program *allocates* them for use.  So in no way can
hdd buffers be considered "system allocated."

Also... I'm curious as to what you believe the function close() does, as
opposed to fclose().  Or what write() does as opposed to fwrite(), or
open() as opposed to fopen().  Or what you think fflush() does and what
reason you believe for there to not be any equivilant flush() function.

-- 
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.

--

From: "Tom St Denis" [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: Text of Applied Cryptography .. do not feed the trolls
Date: Mon, 12 Mar 2001 02:24:40 GMT


"Ryan M. McConahy" [EMAIL PROTECTED] wrote in message
news:3aac1d41$0$62147$[EMAIL PROTECTED]...
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Actually, I was not asking for noise. I merely wanted an address. I
 knew that an electronic version was available. I am a teenager, and
 do not have much money, and would prefer it in an electronic version.

Big deal?  I got a job when I was 15 and bought my own copy.  It's called
the "real world".

Tom



--

From: "Ashish Kasturia" [EMAIL PROTECTED]
Crossposted-To: rec.puzzles
Subject: Re: An extremely difficult (possibly original) cryptogram
Date: Sun, 11 Mar 2001 22:00:49 -0500

 In general, postings of this type are frowned upon.
why is that?
(just a question)
-ash




--

Date: 12 Mar 2001 02:57:32 -
Fr

Cryptography-Digest Digest #868

2000-10-07 Thread Digestifier

Cryptography-Digest Digest #868, Volume #12   Sat, 7 Oct 00 22:13:01 EDT

Contents:
  Re: i should have finished high school (Scott Craver)
  Re: Serial number scheme using DSA variant ("Lyalc")
  Re: NSA quote on AES (John Savard)
  Re: Rijndael (John Savard)
  Re: Why wasn't MARS chosen as AES? (John Savard)
  Re: NSA quote on AES (John Savard)
  Re: It's Rijndael (John Savard)
  Re: Pencil and paper cipher. (John Savard)
  Re: Could NSA help vigilance? (John Savard)
  Re: Looking Closely at Rijndael, the new AES (John Savard)
  Re: NSA quote on AES (John Savard)
  Re: It's Rijndael (John Savard)
  Re: My Theory... (John Savard)
  Re: NSA quote on AES (John Savard)
  Re: Rijndael Coverage Improved on Web Site (John Savard)
  Re: Why trust root CAs ? ("Lyalc")



From: [EMAIL PROTECTED] (Scott Craver)
Crossposted-To: sci.astro,sci.physics.relativity,sci.math
Subject: Re: i should have finished high school
Date: 8 Oct 2000 01:12:28 GMT

Paul Lutus [EMAIL PROTECTED] wrote:

The lighthouse effect is not an FTL effect. Not apparent, not real. Imagine
the water coming out of a swinging hose. None of the water travels at
greater than the basic stream velocity. It's the same with light.

Right.  This guy is basically suggesting that random-access
of data happens at "faster than light" speeds if serial access
of that same data requires faster-than-light travel.

For instance, a terabyte stored on one roll of paper tape
(quick, somebody start planting trees) would probably require
FTL travel to shuttle to a random byte in less than 1 second.

-S


--

Paul Lutus
www.arachnoid.com







--

From: "Lyalc" [EMAIL PROTECTED]
Subject: Re: Serial number scheme using DSA variant
Date: Sun, 8 Oct 2000 12:28:56 +1000

Why don't you use the simple process used in ATMs and EFTPOS globally today?
In essence, encrypt the data with a DES key in CBC, and keep only 32 bits
from the last 8 bytes  of result.  Including the serial number on the
encrypted data will help ensure uniqueness of the result to the serial
number and the data.

Change the key every message if you want, but for the criteria you've
outlined, a single key may be sufficient.

With RSA, DSA or DES (or anything else using crypto), there are identical
key storage security issues.

Lyal

[EMAIL PROTECTED] wrote in message 8ro2fb$o4b$[EMAIL PROTECTED]...
Hi!

First of all thanks for your help regarding short signatures.

After a while I came up with a scheme which could be the solution for
my problem.

I will sum up the requirements first so you can see for yourself if the
scheme meets those criteria.

This scheme will be used for secure serial numbers secure meaning that
no one else is able to forge serial numbers i.e. serial numbers can
only be given out by someone knowing the private key.

Requirements:
   - serial numbers must be short (40 base32 characters at the most)
   - serial numbers can be verified in reasonable time in the software
   - no one should be able to generate serial numbers but me
 (Security equal to cracking DES is secure enough)
   - Only 16384 unique serial number required

Scheme:

I want to employ a DSA variant using only 128 bits for q instead of
160. The part of the signature for all possible messages (16384) which
is not dependant on the message is deployed with the software (the r
part in DSA). Therefore the application needs to store 16384*128 bits =
256 kbytes. The serial number will be delivered as

unique serial number|signature (s part)

thus taking up exactly 142 bits = 29 base-32 characters.
On runtime this serial number

Do you think this is secure? Any objections to this design?

As I understand it I do not need to hash the unique serial number
(otherwise I could use MD5 for example). Is this correct?

Thanks for your help...

kryps


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



--

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NSA quote on AES
Date: Sat, 07 Oct 2000 17:16:33 GMT

On Sat, 7 Oct 2000 11:17:39 +0100, "Brian Gladman"
[EMAIL PROTECTED] wrote, in part:
"David Schwartz" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...

 When a statement appears to be carefully crafted, I assume it means
 exactly and only what it says. I disregard all implications. I think
 this is the correct way to read NSA statements.

In principle I agree with this approach and I believe that it leads to a
sensible conclusion in this case.   Unfortunately, however, very few
statements of any length in english are devoid of the need for
interpretation of some kind so the approach does not always produce the
right answer (if there ever is such a thing).

Since it is seldom the practice of people to craft their st

Cryptography-Digest Digest #868

2000-05-27 Thread Digestifier

Cryptography-Digest Digest #868, Volume #11  Sat, 27 May 00 02:13:01 EDT

Contents:
  Re: Anti-Evidence Eliminator messages, have they reached a burn-out point? ("Klaus 
Daehne")
  Re: safer style sboxes (zapzing)
  Re: Retail distributors of DES chips? (Paul Rubin)
  Re: Matrix key distribution? ("Michael Brown")
  Re: Retail distributors of DES chips? (Paul Rubin)
  looking for an 8-byte long output  hashing function ("Jean-Luc")
  Re: Crypto patentability (Bill Unruh)
  Re: Q: appropriate number of key-uses before replacement? ("Lyalc")
  Enigma reflectors ("Thomas M. Sommers")
  Re: looking for an 8-byte long output  hashing function (Boris Kazak)
  Short signatures (David Hopwood)
  Re: Q: OFB (David Hopwood)
  Short signatures (David Hopwood)
  Re: Anti-Evidence Eliminator messages, have they reached a burn-out point? (Johnny 
Bravo)



From: "Klaus Daehne" [EMAIL PROTECTED]
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out point?
Date: Fri, 26 May 2000 19:36:17 -0700

=BEGIN PGP SIGNED MESSAGE=
Hash: SHA1

Besides the fact that EE is crossposting and posting off topic, I
wound up downloading their product before this debate started, and
(so far) have nothing bad to say.

Aureate, without any doubt, has been caught doing something
incredibly sneaky and despicable (as do the shareware authors that
subscribe to this crap). Unless I am missing something, the same
cannot be said about EE, correct?

If not, are they proven spyware, do they include spyware, or is it
just their crossposting and public neener-ing that has everyone up in
arms?

I (used to) most of my wiping with bcwipe commands in batch files,
which works very well, although I do appreciate the include/exclude
management of EE. It also used to be a pain to locate (and remember)
where OE keeps it's files, so locating this and other folders
automatically is nice.

And, I =did= learn something new: that Windows keeps a "hidden
encrypted database in the system registry which remembers...
information about what you have clicked on your start menu", even if
you wiped the history itself. Intriguing. I wonder what else Windows
is hiing. Oh yeah, and the help file is nice, too.

Not only am I posting this non-anonymously, I am going to sign it,
too, so there is at leat =some= content related to this ng :)

 At this point in time I am neutral on this debate, as I was with
 the Aureate debate.  What I don't understand is, in both cases, the
 side in favor of the software company, claims that posts from
 anonymous posters are less valid than someone w/ a traceable e-mail
 address.  To me, it makes no sense at all even though I am not
 posting anonymously.
donoli.

=BEGIN PGP SIGNATURE=
Version: PGP Personal Privacy 6.5.2

iQA/AwUBOS80aPUjnALVMPh2EQIR9ACfc4j2gMBoZTMJ+H7BDtrCRbMr1wQAnRDn
wZ/4ZMxOuguYExcRXcBcQqXn
=oR9K
=END PGP SIGNATURE=




--

From: zapzing [EMAIL PROTECTED]
Subject: Re: safer style sboxes
Date: Sat, 27 May 2000 02:36:00 GMT

In article [EMAIL PROTECTED],
  Jerry Coffin [EMAIL PROTECTED] wrote:
 In article 8gfjlh$ib5$[EMAIL PROTECTED], [EMAIL PROTECTED] says...

 In fairness, I think there's more than practicality at work here
 though: as Bruce Schneier has pointed out, it doesn't take much
 talent to design a cipher that's probably secure as long as you don't
 mind designing something that's slow, takes lots of memory, and so
 on.  For most cryptologists, the challenge is in creating a cipher
 that uses the bare minimum of resources, but still makes optimal use
 of the key and provides as much security as possible for that key
 size.


I think you have hit the nail on the head.
Another word for it would be "Brinksmanship".
Just why cryptologists do this is unclear.



 The universe is a figment of its own imagination.


--
If you know about a retail source of
inexpensive DES chips, please let
me know,  thanks.


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

--

From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Retail distributors of DES chips?
Date: 27 May 2000 02:50:08 GMT

In article 8gn72l$2vq$[EMAIL PROTECTED], zapzing  [EMAIL PROTECTED] wrote:

Yup. tamper resistance is the point.  I can't find your stuff about
"java buttons" but that doesn't mean much since deja has been so
flakey lately.

http://www.ibutton.com/java/

But how could something written in Java be considered a hardware
solution? Is this a microprocessor application?

Yes.  The button has a secure microprocessor sealed inside, that
runs a subset of Java.  You write mini-applets and load them into
the button.

--

From: "Michael Brown" [EMAIL PROTECTED]
Subject: Re: Matrix key d

Cryptography-Digest Digest #868

2000-01-08 Thread Digestifier

Cryptography-Digest Digest #868, Volume #10   Sat, 8 Jan 00 11:13:00 EST

Contents:
  Re: frequency analysis with homophones (Mok-Kong Shen)
  Re: I want to know if this works? (Mok-Kong Shen)
  Re: Intel 810 chipset Random Number Generator (Guy Macon)
  Re: AES3 Conference: deadline for papers *18*/01/2000 (David Crick)
  Re: OLD RLE TO NEW BIJECTIVE RLE (John Savard)
  Re: Truly random bistream (Michael)
  modifiec game of life encryption, to be analyzed ([EMAIL PROTECTED])
  Re: Questions about message digest functions (Tim Tyler)
  Re: OLD RLE TO NEW BIJECTIVE RLE (Tim Tyler)
  Re: is signing a signature with RSA risky? (Tim Tyler)
  Re: Followup:  Help Needed For Science Research Project (Paul Crowley)
  Re: is signing a signature with RSA risky? (Tim Tyler)



From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: frequency analysis with homophones
Date: Sat, 08 Jan 2000 12:59:20 +0100

r.e.s. wrote:
 
 : The fundamental problem I can see is the non-reversibility of
 : implication. That is, if one uses J homophones for each plaintext
 : character, then one has the frequency distribution you obtained.
 : But the implication in the reverse direction is not logically sound.
 : (Equivalence has to be proved in logic.)
 
 The fundamental problem, I'm afraid, is that you're looking at what
 the data does or does not "logically imply", while the issue is one
 of plausible inference in the presence of uncertainty -- not one of
 strict logical implication.  That is why the problem is posed as a
 statistical one in the first place.

Unfortunately, in cryptanalysis, as far as I am aware, one often needs
quite a lot of guesswork/speculations/intuitions as well as good luck. 
Rational mathematical arguments alone frequently don't help one very 
far. In my humble opinion (from what I have sofar understood from 
your description) the 'statistical significance' of the sort that 
you found is of such 'uncertainty' (on the scale of my personal 
'subjective' measure) that I wouldn't start put much energy 
straightaway in following the direction 'indicated' by the computing
results. (I consider namely that the result being a 'chance 
coincidence' to be pretty high.) Well, this is just my personal 
standpoint, probably biased due to my poor knowledge and experiences.
You and others may well have the very opposite standpoint. Obviously,
however, this is analogous to a question of tastes and couldn't be 
settled by mathematics or such. For else a follow-up of someone 
would have already put an immediate end to that issue.

 
 Nobody knows the exact distribution, nor does the statistical
 approach attempt to "deduce" exact results.  The problem is one of
 plausible *induction*, not deduction.

Right. But exactly here lies the source of difficulty. What is 
plausible to me is not necessarily plausible to you and vice versa.
Look into what the AI people work on induction and fuzzy reasoning. 
They haven't yet gone very far in my humble view. Anyway, their 
current tools wouldn't help you much in the present case in my 
conviction.

M. K. Shen

--

From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: I want to know if this works?
Date: Sat, 08 Jan 2000 13:09:03 +0100

Jeff Lockwood wrote:
 
 /***
 rat data stream scrambler:
 
 try it out.

It is always preferable to let other people discuss your design
principles/rationales rather than discuss your C-codes or even 
actually run the codes, if you really intend to know if what you
designed works.

M. K. Shen

--

From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 08 Jan 2000 07:36:24 EST


http://developer.intel.com/design/chipsets/rng/docs.htm

http://developer.intel.com/design/chipsets/datashts/290658.htm

http://www.intel.com.ec/design/chipsets/rng/faq.htm

http://www.rsasecurity.com/products/bsafe/intel/

http://www.rsasecurity.com/products/bsafe/intel/rsa_rng_nontech.pdf

http://www.rsasecurity.com/products/bsafe/intel/rsa_rng_tech.pdf


--

From: David Crick [EMAIL PROTECTED]
Subject: Re: AES3 Conference: deadline for papers *18*/01/2000
Date: Sat, 08 Jan 2000 12:43:12 +

David Crick wrote:
 
 A reminder:
 
 "Paper submission deadline: January 15, 2000"
 
 See: http://csrc.nist.gov/encryption/aes/round2/conf3/aes3conf.htm
 and  http://csrc.nist.gov/encryption/aes/round2/conf3/aes3cfp.htm
 and  http://csrc.nist.gov/encryption/aes/aes_home.htm

from the third link above:

 "Due to a Federal Government holiday on Monday, January 17, paper
 submissions for AES3 may be submitted to NIST up until 9:00 am
 Eastern Standard Time on Tuesday, January 18."

-- 
+---+
| David Crick  [EMAIL PROTECTED]  http://members.tripod.com/v

Cryptography-Digest Digest #868

1999-01-08 Thread Digestifier

Cryptography-Digest Digest #868, Volume #8Fri, 8 Jan 99 22:13:03 EST

Contents:
  Re: OCX/DLL wanted ("Morten H. Nielsen")
  example with concrete numbers of blind signature (sos)
  Re: Factoring ("Yves Gallot")
  Re: On the Generation of Pseudo-OTP (wtshaw)
  Re: RSA question ([EMAIL PROTECTED])
  Re: On the Generation of Pseudo-OTP (Paul L. Allen)
  A method on finding the cheater in sharing scheme. (xlzhu)
  Re: ScramDisk - password size - high ASCII (wtshaw)
  Re: Triple DES with CBC (DJohn37050)
  Attention:  This is an encoded message? (EvanPic)
  Re: On leaving the 56-bit key length limitation ([EMAIL PROTECTED])
  Triple DES with CBC ("Steven H. McCown")
  Re: Learn Encryption Techniques with BASIC and C++ (CryptoBook)
  Re: RSA-Modulus decomposition (Robert I. Eachus)
  Re: On leaving the 56-bit key length limitation (wtshaw)



From: "Morten H. Nielsen" [EMAIL PROTECTED]
Subject: Re: OCX/DLL wanted
Date: Fri, 8 Jan 1999 22:23:17 +0100

Try this link One of the BEST

http://sevillaonline.com/ActiveX/


Jonas Westberg skrev i meddelelsen 774vgh$c8v$[EMAIL PROTECTED]...
Please let me know if you know of any Components that can be used in Visual
Basic applications (OCX/DLL).

- Public Key Algorithm (RSA key generation, encryption and signing)
- Secret Key Algorithm (free block- or fiestelchipher like CAST)

Thanks

Jonas Westberg
[EMAIL PROTECTED]







--

From: sos [EMAIL PROTECTED]
Subject: example with concrete numbers of blind signature
Date: Fri, 08 Jan 1999 23:25:25 +0100

For a small treatise I am looking for an example with concrete numbers
of blind signature. 
I think I understand all the formulas, but I can not achieve a
reasonable results.

All publications I found only give some hints how it works and what the
formulas are. Maybe there you can give me an internet location that can
help me.

Please mail me directly.

Soeren Schmidt

--

From: "Yves Gallot" [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: Factoring
Date: Sat, 9 Jan 1999 00:19:18 +0100


Thank you very much for your excellent program!

Yves




--

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: On the Generation of Pseudo-OTP
Date: Fri, 08 Jan 1999 16:32:11 -0600

In article [EMAIL PROTECTED], Mok-Kong Shen
[EMAIL PROTECTED] wrote:
 
 However the context of my proposal is that one can only get
 56-bit cryptos (and very likely only software). So I think that even 
 a not so good approximation of an OTP helps to a certain degree, for 
 it can be used in  conjunction with a 56-bit crypto software and
 enhance its strength. We have to collect all useful things and 
 combine them, so that those who can only get 56-bit cryptos (those 
 outside of the 33 countries) can still obtain adequate security
 in their communications.
 
All it takes is a little creative chaining to even if single algorithms
are 56 bit cryptos.  Consider what intermediate steps might be needed to
strip away headers that anounce what algorithm was used. The fact being
that it is not easy to determine that a 56 bit limit was surpassed or
wasn't, except that the hall-monitor might be upset that their techniques
of retreving plaintext did not work.  No, a 56 bit limit does not do much
in itself, which is the point.

Look next for severe restrictions for using only very few algorithms.
-- 
If government can make someone answer a question as they want him to, they can make 
him lie, then, punish him for not telling the truth. Such an outrage constitutes 
entrapment. 

--

From: [EMAIL PROTECTED]
Subject: Re: RSA question
Date: Fri, 08 Jan 1999 21:56:35 GMT

The security of RSA is conjectured to be based upon the Integer Factorization
Problem (IFP), but this link has never been proved.

Recently, a paper “Breaking RSA may not be equivalent to factoring” by D.Boneh
 R.Venkatesan published in Eurocrypt '98 shows some classes of the RSAP which
are not equivalent to the underlying IFP.

It _may_ be possible to break RSA without factoring...


Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption 
Delphi Crypto Components.  PGP Keys available at the same site.

In article 9DB141BB95ACD978.552D4BEF2C5C8648.1961F2B1F78F3098@library-
proxy.airnews.net,
  Rx Video [EMAIL PROTECTED] wrote:
 Hello,

 I've recently read through the theory on RSA algorithm. I just wanted to
 make sure if the factorization of the N (modulus) number is the keystone
 of its security ?
 p*q=N - I have not tried to compute all the possible values for p and q
 with known N, but the approach to find those values would be to divide N
 by i, with i increasing with every step (or changing i to the next prime
 number), until one of p or q is found. I do not know how difficult that
 task is for