Cryptography-Digest Digest #141, Volume #11      Thu, 17 Feb 00 10:13:01 EST

Contents:
  Re: Does the NSA have ALL Possible PGP keys? ([EMAIL PROTECTED])
  elliptic curve DSA approved as US government standard (Alfred John Menezes)
  Re: EOF in cipher??? (JPeschel)
  Re: UK publishes 'impossible' decryption law (Richard Herring)
  NSA Linux and the GPL (John Savard)
  Re: EOF in cipher??? (Runu Knips)
  Re: Using virtually any cipher as public key system? (Mikko Lehtisalo)
  Re: Question about OTPs ("Tony T. Warnock")
  Re: Question about OTPs ("Dr.Gunter Abend")
  Re: Does the NSA have ALL Possible PGP keys? ("tiwolf")
  Re: Does the NSA have ALL Possible PGP keys? ("tiwolf")
  Re: EOF in cipher??? ([EMAIL PROTECTED])
  Re: PhD in Cryptography? (Anton Stiglic)
  Re: Using virtually any cipher as public key system? (Anton Stiglic)
  Re: multi-precision integer C library (Nathan Kennedy)

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

From: [EMAIL PROTECTED]
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Thu, 17 Feb 2000 12:36:07 GMT

In article <[EMAIL PROTECTED]>,
  drickel <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, "tiwolf"
> <[EMAIL PROTECTED]> wrote:
> >Anything is possible given time, money, and talent. Government
> has nothing
> >to do with it. In this case the government desire to control
> along with
> >access to money (tax payers), and (through the obscene spending
> of the
> >taxpayers money) talent. This makes the probability high that
> people will
> >break any code given the right equipment and time.
>
> Bullshit.  The universe operates according to laws (we might not
> know the laws, but we have some ideas).  These laws cannot be
> broken, no matter how much money and talent you throw at it.
>
> Just for a start--most of Mozart's atoms are still around.  How
> much money and talent would it take to find them all and put them
> back together?  Say, exactly as he was, Jan 1, 1790, 0:00:00 GMT
> (it's ok to use replacement atoms for any that have split or
> fused in the interim).

But beside of these calculation, one always have to bear in mind that
mathematical breakthroughs have always been achieved and will be achieved
in future. And as there aren't that many mathematicians in the world that
work on number theoretic problems relevant to public key crypto,  it
might be possible to surveille them all. Most countries in the world have
laws that allow to disclose information and research discoveries if the
national security is concerned. So theoretically, any organization could
be in knowledge of some mathematical breakthrough that makes decyphering
PGP messages trivial.

However, of course, this applies to *all* kind of cryptographic protocols
and algorithms, and there's no reason to assume that any of such
breakthroughs has been achieved. I don't know for sure, but maybe it's
more reasonable to assume attacks on IDEA and CAST than on the public key
crypto itself. What do you think?

Greetings,

Erich


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

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

From: [EMAIL PROTECTED] (Alfred John Menezes)
Subject: elliptic curve DSA approved as US government standard
Date: 17 Feb 2000 12:44:58 GMT


On February 15 2000, the National Institute of Standards and Technology
(NIST) announced the revision to their Digital Signature Standard (DSS). 
The original DSS (FIPS 186) specified the Digital Signature Algorithm (DSA). 

FIPS 186 was revised in 1998 to include both the DSA and RSA signatures 
as described in ANSI X9.31. The revised standard is FIPS 186-1.

The latest revision, FIPS 186-2, includes the elliptic curve analogue
of DSA (ECDSA) as specified in ANSI X9.62. The latter was approved
as an ANSI standard for financial applications in January 1999.  

What this means is that US government departments are free to choose
between DSA, RSA and ECDSA when selecting a signature algorithm. This is
a *major* endorsement for elliptic curve cryptography (ECC). Keep in mind
that NIST is the organization that gave us DES, DSA, and SHA-1, and
is now leading the AES effort. 

The FIPS 186-2 standard is available from NIST's web site. ECDSA is 
included in FIPS 186-2 simply by reference to ANSI X9.62. Unfortunately,
there is a fee for obtaining the latter from the ANSI organization. If 
you would like to find out more about ANSI X9.62 ECDSA, download the
paper "The Elliptic Curve Digital Signature Algorithm" that I wrote with
Don Johnson from my web page www.cacr.math.uwaterloo.ca/~ajmeneze

- Alfred

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

From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: EOF in cipher???
Date: 17 Feb 2000 13:17:35 GMT

Runu Knips [EMAIL PROTECTED] writes:

>FEOF is not standard. Which compiler defines such a strange variable ?
>EOF works well, because EOF is defined to be -1, while all characters
>are returned as nonnegative values.

FEOF is a standard function. A binary file could have a -1 value within
it, in which case EOF would terminate  before reaching the actual
end of the input. You can also use FEOF for text files.

Joe

__________________________________________

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


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

From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: talk.politics.crypto
Subject: Re: UK publishes 'impossible' decryption law
Date: 17 Feb 2000 13:13:54 GMT
Reply-To: [EMAIL PROTECTED]

In article <[EMAIL PROTECTED]>, Jim ([EMAIL PROTECTED]) 
wrote:
> On Tue, 15 Feb 2000 22:34:03 GMT, "Dave VanHorn" <[EMAIL PROTECTED]> wrote:

> >Things like this make me glad my ancestors booked passage.

> Most of my ancestors didn't have to book, they were put on the
> ship whether they wanted to go or not!

> Nonetheless it was probably all for the good in the end.

Probably increased the average intelligence of both nations ;-)

-- 
Richard Herring      | <[EMAIL PROTECTED]> 

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

From: [EMAIL PROTECTED] (John Savard)
Subject: NSA Linux and the GPL
Date: Thu, 17 Feb 2000 13:15:28 GMT

In the latest CRYPTO-GRAM, Bruce Schneier asked:

"Personally, I don't know if the Linux license allows the NSA to 
make a secure version of the operating system if they are not going to

freely distribute the results."

I remember wading through the GPL. What it says is that if you take
any of the programs distributed under that license, add some of your
own code to them, you can still charge for the result, but you can't
use the fact that there is some code in there that you wrote to
restrict the recipient from freely redistributing the result.

But you certainly can modify Linux for your own use, and decide not to
distribute the modified version to anyone else at all.

So, while any company producing a "Secure Linux" for the NSA cannot
prohibit the NSA from freely passing it out to anyone else it feels
like, the NSA is under no obligation to do so. So, yes, they _can_
'get away' with this.

John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html

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

From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Thu, 17 Feb 2000 14:44:15 +0100

JPeschel schrieb:
> Runu Knips [EMAIL PROTECTED] writes:
> 
> >FEOF is not standard. Which compiler defines such a strange variable ?
> >EOF works well, because EOF is defined to be -1, while all characters
> >are returned as nonnegative values.
> 
> FEOF is a standard function. A binary file could have a -1 value within
> it, in which case EOF would terminate  before reaching the actual
> end of the input. You can also use FEOF for text files.

Aaaaaah you meant feof() !!!!!
Thats something different of course 8-)
Case matters in C !

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

From: [EMAIL PROTECTED] (Mikko Lehtisalo)
Subject: Re: Using virtually any cipher as public key system?
Date: Thu, 17 Feb 2000 13:59:30 GMT

Thank you, I got the picture.. Ah well, it was a nice dream :) Back to
IDEA I guess. How much would you consider a safe keysize giving it was
implemented right?


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

From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: Thu, 17 Feb 2000 07:26:10 -0700
Reply-To: [EMAIL PROTECTED]



Bill Unruh wrote:

> In <[EMAIL PROTECTED]> Arthur Dardia <[EMAIL PROTECTED]> writes:
>
> In a OTP, no byte of the one time pad should ever be reused in any way.
> If a byte is used for any purpose, throw it away and never use it again.
> That is the condition under which a OTP is secure. Anything else and the
> security proof fails. Of course one may be able to argue that some ways
> of reusing the byte are still secure enough, but that is a different
> argument. To be a One Time Pad, the One Time is crucial.

One is One. It doesn't depend on the definition. 1.0000001 is not 1.


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

From: "Dr.Gunter Abend" <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: Thu, 17 Feb 2000 15:34:42 +0100

Mark VandeWettering wrote:
> 
>> Arthur Dardia:  Reusing the pad ("OTP") at different offsets
> 
> The crack proceeds as following:  You can find the offset
> rather easily by basically taking the two texts at different
> offsets, and XORING them together.
> If the two streams are synchronized at the offset you've
> chosen, you get a MASSIVELY different frequency distribution.

Is that still true if you compress the plaintexts beforehand?
Especially if you use a compression algorithm that nearly
completely removes the redundancy of the original byte streams.
You always should compress your texts in order to use less pad
material.  Your suggested crack woun't work:

> ...  you basically just take common words and run them through
> the combined text, and see if real words pop out the other side.
_____________________

> You can't reuse any part of a OTP without seriously
> jeopardizing it's security.  The same error sometimes happens
> when people reuse seed values for stream ciphers.

I'm sure, you're right.  I'd not suggest compression as a *cure*
of the security problem -- I only ask if still a *simple* attack
exists against Arthur's method.

A few months ago, I asked the experts in this group to quantify
the insecurity of a "modified" OTP. They refused, because even my
small manipulation would be a sacrifice to the holy OTP.

I proposed to skip a part of the pad if a spurious accident
happened, i.e. I would like to omit *sending* a certain message,
and use the pad for a different, perhaps a dummy one, or even
discard it completely.

This slight reduction of the security should, as I guessed, render
OTP not worse than other encryption tools with reasonable key
lengths, but omit occasionally sending readable cipher texts.
(Please don't repeat the discussion, *why* I want to avoid
intelligible cipher texts, and how to test it automatically).

I still ask you experts:  please quantify the lack of security!

OTP is an extremely promising technique -- it provides absolute
security (if you have a reliable channel for the transmission of
the pad material, may be long time before you use it), and it is
deniable: As soon as the pad is destroyed you can neither prove
nor disprove the contents of an encrypted message, especially if
you always append some garbage (so that even the length of a
message carries no information).

1. How insecure is an algorithm that skips a few bytes of the pad
(instead of using just the position at the end of the previous
transmission) for those  x %  of all messages that fall through
the "readability" test?

2. How insecure is an algorithm that reuses the pad (instead of
transmitting a new one) in case you run out of material?  You
might reorder the pad by a predefined algorithm so that both
parties can do it identically. I know that the pad is no more
completely random, but it still is randomly distributed, as
before. You might use a few of these permutations -- if you are
sure that you always stay far away from identity.  You might 
prove theoretically whether the permutation algorithm avoids
coincidences. The algorithm may be controlled by a few still
unused bytes of the pad itself so that an eavesdropper only knows
that you used one of a huge number of possible permutations.

I guess:  The length of the "key" for these permutations is a
comparable measure of the security like the key length for other
encryption techniques.  If you append  10.000 keys of 100 bytes
length ( = 1MB ), you can use your pad material 10.000 times.
It should be nearly impossible to hide a backdoor within this
permutation algorithm. Therefore it is more trustworthy than
commercially available complicated cryptosystems.

Ciao,   Gunter

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

From: "tiwolf" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Thu, 17 Feb 2000 06:52:44 -0800

Now Johnny who is blatant stupidity, you claim that even God does not know
what the highest number is. Given that God is created all things in the
universe, and inspired human creativity and invention, how can you say that
God does not know what the highest number is. That would be an indication of
limit and according to the philosophical debate and my religious up bringing
God is limitless in power and knowledge.


Johnny Bravo wrote in message
<[EMAIL PROTECTED]>...
>On Wed, 16 Feb 2000 12:07:11 -0800, "tiwolf" <[EMAIL PROTECTED]> wrote:
>
>>Anything is possible given time, money, and talent.
>
>  How many times are you going to post this blatant stupidity?
>
>  Many things are 100% impossible, finding the biggest number for
>instance.  Get this through your head; some problems do not have a
>solution to find.
>
>>Government has nothing to do with it. In this case the government desire
>>to control along with access to money (tax payers), and (through the
obscene
>>spending of the taxpayers money) talent.
>
>  Make up your mind, does government have something to do with it or not?
>Makes no difference, impossible is just that, impossible.  Even with
>infinite time, money and talent.  Not even God can tell you what the
>biggest number is.
>
>  Johnny Bravo
>



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

From: "tiwolf" <[EMAIL PROTECTED]>
Crossposted-To: misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Thu, 17 Feb 2000 06:59:52 -0800

Considering the founders of our Republic believed that power can and does
corrupt and that government institutions can be used to attack the personal
liberty and freedom of American citizens, it should be no mystery why we
Americans fear government agencies. Also knowing that government is more
than willing to keep and use information i.e. Hoover's secret files, the
recent scandal of the Clinton Administration collection of FBI files used
"to do background checks" in open violation of federal law. these are just a
few reason why American fear government agencies.


[EMAIL PROTECTED] wrote in message <88gofs$v9o$[EMAIL PROTECTED]>...
>
>
>> This is a claim distinct from the statement that NSA has "all possible
>> keys".  It amounts to the claim that the NSA has or can obtain all keys
in
>> use.  While this claim cannot be refuted by size-of-the-universe
>> calculations, it still requires substantial support to be credible.
>>
>> To me it looks pretty nekkid.
>
>Well, any basic skilled hacker can get *your* private key plus keyphrase,
>and so probably does the NSA. See my other reply for an explanation why.
>
>It's another question wether the NSA does actively collect anyone's keys
>without the person being a special target. I am not an American and I
>must admit that there's a strange paranoia of US citizens towards their
>own agencies. I have no clue why the people always fear the NSA and not
>equivalent foreign agencies. Seems to have something to do with the
>federal structure and the size of the USA, but this irrational distrust
>against the government is something foreigners have problems to
>understand.
>
>Regards,
>
>John Stone
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.



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

From: [EMAIL PROTECTED]
Subject: Re: EOF in cipher???
Date: Thu, 17 Feb 2000 14:51:50 GMT

Thanks guys.  I don't know what I was thinking.  Opening the files as
binary solved a couple problems at once!!

In article <[EMAIL PROTECTED]>,
  "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> When reading random bit patterns, the program should not perform any
> text format interpretations.  In C, the file should be opened as a
> binary stream, not a text stream.
>


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

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

From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: PhD in Cryptography?
Date: Thu, 17 Feb 2000 10:06:38 -0500

Nathan wrote:

> [...] I haven't decided myself), especially in Canada, would be most
> helpful.
> Thanks in advance.

In canada there is university of Waterloo (Toronto) and McGill (Montreal).
There might be other good ones that I don't know about.

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

http://crypto.cs.mcgill.ca/

Anton


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

From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Using virtually any cipher as public key system?
Date: Thu, 17 Feb 2000 10:08:34 -0500

Tom St Denis wrote:

> In article <[EMAIL PROTECTED]>,
>   Anton Stiglic <[EMAIL PROTECTED]> wrote:
> >
> > --------------3D7C6BA71BE643ED4FB09901
> > Content-Type: text/plain; charset=us-ascii
> > Content-Transfer-Encoding: 7bit
> >
> > Mikko Lehtisalo wrote:
> >
> > > I read a long time ago some book and in it was the instructions how
> to
> > > use any algorithm (for instance des) as a public key system.. It
> > > involved something like creating two keys and ciphering random data
> > > and moving it blahblah.. Can't even remember what the technique is
> > > called :( Any info?
> >
> > A simple way to achieve some kind of public key crypto using symmetric
> > algorithms is by using a half-certified diffie-hellman static public
> key
> > agreement (sometimes called ElGamal key agreement, and a whole bunch
> > of other variations of the key words).
> > It simply goes like this:
> >
> > like in DH, there is a publicly known generator g,
> >
> > Alice computes g^a (for some randomly chosen a) and publicly publishes
> > it somewhere (if you have signature schemes, she could sign it, but
> that
> > uses
> > public-key crypto...).
> >
> > So now, when some guy, say Bob, wants to communicate with Alice,
> > he simply takes g^a,  computes (g^a)^b for some randomly chosen b
> > and sends g^b to Alice.   Alice, upon receiving this g^b, computes
> > (g^b)^a (just like DH).
> > (g^a)^b is now a shared secret, which can be used to generate a key
> for
> > a symmetric algorithm.
> > If Carl also wants to communicate with Alice, he does the same thing.
> > It's not asymmetric crypto, but its kind of public key crypto....
> >
> > This is actually what is used in the Freedom software (as described in
> > the white paper)....
>
> Actually what you described is public key cryptography.  Where (g^a mod
> p) is your public key and 'a' is your private key.  Just because you
> are not encrypting with it, does not mean it ain't PK.

That is what I said....  making a distinction between symmetric encryption
and public key encryption.




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

From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: multi-precision integer C library
Date: Thu, 17 Feb 2000 23:04:12 +0800

BBC-Igor wrote:

> Can anyone point me in the right direction of a well-documented multi-precision 
>integer arithmetic C library?

I recommend gmp, from your local GNU archive.  See www.gnu.org.  It is very easy to 
use, well-documented, and
free (GPLed).  It is not the most efficient multiple-precision library out there (it 
doesn't do FFT, it uses
integer operations), however it is still very fast and suitable for cryptographic 
purposes.

Nate


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


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