Cryptography-Digest Digest #135, Volume #11 Wed, 16 Feb 00 17:13:01 EST
Contents:
Re: Guaranteed Public Key Exchanges (Ralph Hilton)
Re: Q: Division in GF(2^n) (Mike Rosing)
Re: NTRU Speed Claims (100x faster, etc.), explained (Mike Rosing)
Re: Large Floating Point Library? ("Dann Corbit")
Re: OTP practical implementation (Johnny Bravo)
Re: Q: Division in GF(2^n) (Paul Koning)
Re: source code export laws (Paul Koning)
Re: OTP practical implementation (Paul Koning)
Re: OTP practical implementation (Andru Luvisi)
Re: UK publishes 'impossible' decryption law (Jim)
Re: OTP practical implementation (Jim)
Re: EOF in cipher??? (Stephen Houchen)
Re: Does the NSA have ALL Possible PGP keys? ("tiwolf")
RSA Speed (Erik)
Re: EOF in cipher??? (John Savard)
multi-precision integer C library ("BBC-Igor")
Question about OTPs (Arthur Dardia)
Re: EOF in cipher??? ("Douglas A. Gwyn")
Re: Hardware crypto device (Arthur Dardia)
Re: New standart for encryption software. (Albert P. Belle Isle)
Re: Does the NSA have ALL Possible PGP keys? (drickel)
Re: Does the NSA have ALL Possible PGP keys? (Mark VandeWettering)
----------------------------------------------------------------------------
From: Ralph Hilton <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
Date: Wed, 16 Feb 2000 19:10:04 +0100
Reply-To: [EMAIL PROTECTED]
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
On Wed, 16 Feb 2000 17:42:56 GMT, Darren New <[EMAIL PROTECTED]> wrote:
>Ralph Hilton wrote:
>> Because either John or Mary or each individually would have a secret
>> number used to create their part of the key and couldn't read each
>> others messages (unless they tell each other which means that one is
>> effectively dealing with one correspondent anyway).
>
>You still can't tell whether John has generated all the keys, or whetehr
>Mary has generated all the keys.
True. There is that liability.
>> I would suggest that if one's boss is willing to send trade secrets to
>> Joe Hinkle only knowing his name and email address then he deserves his
>> inevitable fate.
>
>Oh, the *boss* knows Joe very well. *You* don't. And the boss is way too
>busy to bother about getting fingerprints or anything. After all, *you*
>are the cryptographer. ;-)
>
>> In a totally theoretical model I can't fault your reasoning. The
>> original question appeared to me to be founded on a possible realistic
>> situation.
>
>Yes. The original question was "you have an email address for Joe. How do
>you exchange keys securely." Scroll back in the thread. :-)
That was my impression too.
One would have to extract all the information from the boss that would
could for verification. If he isn't willing to spend the time providing it
then the company is out of pocket.
=====BEGIN PGP SIGNATURE=====
Version: 6.5.1ckt
iQA/AwUBOKrZ50Cdrg0RcyHQEQL2twCgiH5UtNOd40ihjVyMBSIvSQsH1jYAoOc6
5TbIGSnzHXFkL0vEPELEKFyX
=+LJ7
=====END PGP SIGNATURE=====
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Q: Division in GF(2^n)
Date: Wed, 16 Feb 2000 12:24:24 -0600
Mok-Kong Shen wrote:
> > However, AFAICS it is *much* less efficient (at least for software
> > implementations with field sizes of interest in cryptography) than
> > calculating the inverse of B using the Almost Inverse algorithm, and
> > multiplying A by the inverse.
>
> Why is that 'Almost'? Isn't it exact, if one uses B^(-1)=B^(2^n-2)?
That's the name given to an algorithm published by Schroppel a few years
back.
You end up with 1/B * u^k, and for some systems inverting u^k is simple.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: NTRU Speed Claims (100x faster, etc.), explained
Date: Wed, 16 Feb 2000 12:34:15 -0600
[EMAIL PROTECTED] wrote:
> NTRU has posted an update to our FAQ which explains how our speed
> claims were derived. Please take a look at
> http://www.ntru.com/tech.learning.faq.htm#Why is NTRU fast
> (there is a link from the main page - www.ntru.com - at the bottom
> of the page) if you are interested.
Thanks for the pointer. Looks like a healthy respect for the net.
That's a pretty good sign it's worth checking out.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Dann Corbit" <[EMAIL PROTECTED]>
Subject: Re: Large Floating Point Library?
Date: Wed, 16 Feb 2000 10:47:14 -0800
"Clockwork" <[EMAIL PROTECTED]> wrote in message
news:PrMp4.663$[EMAIL PROTECTED]...
> There are numerous large integer libraries, but does anyone know of a
large
> floating point library?
Fortran:
BMP by Brent is very nice and ports very easily to many systems. Very
extensive and also has a C++ interface.
C++:
MIRACL by Scott has a rational number class that suffices for floating
point. Good for several hundred digits. Easiest program to port that I
ever saw. Also has a C binding. An excellent big integer class is included
as well. One of my all time favorites. I use this for any sort of
factoring problem. It's also a wonderful study in factoring algorithms,
modular arithmetic and a number of related topics. You should definitely
take a look if you are interested in using C++. It is free for academic use
and has a one time $500 charge for commercial use (last time I looked).
QFLOAT by Moshier is very good for up to 50 digits or so. Ports very
easily. Also has a C binding. I use this for database work.
APFLOAT by Tommila and HFLOAT by Arndt are good for thousands of digits, but
require GCC (does not work at all on many other compilers that I have
tried -- literally thousands of compile errors). I use this for enormous
problems that require tens of thousands of digits or more.
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. Newsgroup http://www.dejanews.com/~c_a_p
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: OTP practical implementation
Date: Wed, 16 Feb 2000 13:58:33 +0000
On Wed, 16 Feb 2000 07:41:52 -0800, Anthony Stephen Szopa
<[EMAIL PROTECTED]> wrote:
>J. Bravo wants you to believe it would be easy.
He wants to XOR data from a CD with his data and keep track of the
offset, how hard is that?
>Like all programming, it is simple. But it gets very complicated
>very quickly.
Not if you do it correctly.
> It almost sounds like he has my encryption
>software.
I have no idea what your software is, much less have a copy.
Johnny Bravo
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Q: Division in GF(2^n)
Date: Wed, 16 Feb 2000 13:25:01 -0500
Well, certainly patenting mathematics is as absurd as patenting
genetics, but both seem to be permitted by the US patent office
these days. Whether that's because of some random decisions they
made or because of real legal authority is entirely unclear to me.
But you don't need to worry about most of the cases you mentioned.
School math is clearly not patentable -- it's not "novel". So while
a patent covering school math would probably be approved given
how the patent office "operates" these past few years, that patent
would nevertheless not be valid and would not hold up under
challenge, which is what matters most.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: source code export laws
Date: Wed, 16 Feb 2000 13:29:03 -0500
wtshaw wrote:
>
> In article <[EMAIL PROTECTED]>, Jeremiah
> <[EMAIL PROTECTED]> wrote:
>
> > I am wanting to put the source code of a lot of encryption algorithms up
> > on the internet. What are the laws for me doing this?
>
> I suggest that it depends what algorithm and if it bothers someone in
> authority, as so much of the government chinese fire drill on the subject
> is pathetic or laughable.
>
> Let me make a point or two with some code. ROT13 should be tame enough:
You probably should have sent a copy of that to the BXA before you
posted
it (if you're in the USA). :-)
Jeremiah, if you're in the USA, read the current regulations at
www.bxa.doc.gov.
They have changed significantly, and the info that Lassi pointed to may
not
be updated yet.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: OTP practical implementation
Date: Wed, 16 Feb 2000 13:32:10 -0500
Johnny Bravo wrote:
> ...
> >(does the offset information travel with the encrypted data as clear text?)?
>
> It would be easiest to send it in the clear as the start of the message
> as a 4 byte value, and would not leak anything unless you have an extra
> copy of the CDs floating around somewhere unaccounted for. In which case
> the offset is not enough security, and a secondary password might be
> helpful if you have such a need for security.
No, actually... if there's an unaccounted copy of the CDROM somewhere,
you've lost all security. If the bad guy has that CDROM, he can simply
try XORing your ciphertext at all possible offsets looking for
plaintext,
that won't take long at all.
paul
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: OTP practical implementation
Date: 16 Feb 2000 11:04:19 -0800
Dan <[EMAIL PROTECTED]> writes:
> As a given, assume that I have two identical sets of n CD-ROMs each
> containing 650Mb of true random data. Each CD-ROM also has a unique
> internal and external id.
>
> Is there any available software, hopefully shareware/freeware, that
> manages the practical use of my random data as an OTP? Specifically the
> reformatting of the text, encryption/decryption of the text and
> management of the offset within the random data to start the
> encryption/decryption (does the offset information travel with the
> encrypted data as clear text?)?
>
> Thanks for your time and help.
Assuming that the machines you are performing encryption and
decryption on are both secure (I'll let you worry about what that
means), it's fairly easy. One crude example:
#include <stdio.h>
int main(int argc, char **argv, char **envp) {
FILE *fp;
int i;
if(argc != 2) {
fprintf(stderr, "Usage: %s <file>\n", argv[0]);
exit(1);
}
if((fp = fopen(argv[1], "r")) == NULL) {
fprintf(stderr, "Can't open %s\n", argv[1]);
exit(1);
}
while((i = getchar()) != EOF) {
putchar(i ^ fgetc(fp));
}
fclose(fp);
exit(0);
}
You could use this with (assuming an offset of 400):
dd bs=1 skip=400 if=/dev/cdrom |otp /file/to/encrypt > /encrypted/file
The offset information could travel however you like. In the clear
would probably be easiest. Or the receiver could just keep track of
how many bytes he's received in previous messages. As others have
said, the important thing is not to use the same key data to encrypt
more than one piece of plaintext.
Andru
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
From: [EMAIL PROTECTED] (Jim)
Crossposted-To: talk.politics.crypto
Subject: Re: UK publishes 'impossible' decryption law
Date: Wed, 16 Feb 2000 19:22:49 GMT
Reply-To: [EMAIL PROTECTED]
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.
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: OTP practical implementation
Date: Wed, 16 Feb 2000 19:22:51 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 16 Feb 2000 01:04:30 +0000, Johnny Bravo <[EMAIL PROTECTED]> wrote:
> It would be very important to ensure that no two messages are sent with
>the same random data. You can assign blocks of bytes to be used by each
>party. If you know before hand how many senders you have, create a
>different file for each sender on the CD. Each sender starts at the front
>of the file and remembers the stopping position as each message is sent,
>the recipients will have the offset in each message.
Then it gets difficult......
That system allows any one sender to read the traffic of any other
sender, given that he can intercept other senders' traffic.
It becomes much more hairy if traffic between two senders must be
secure from other senders.
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
From: Stephen Houchen <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Wed, 16 Feb 2000 13:52:36 -0600
> Question is: What do most algos do when the output is going to be EOF?
> Example say I do some bit shifting, xoring etc and I'm outputing the
> encrypted results to a file. If one of the chars in the stream when
> encrypted happens to be EOF (Ascii #26) then when my program reads it
> back in for Decryption it stops at that character.
If you're programming in C, open the file as "binary" (mode "rb", for
example).
S
[EMAIL PROTECTED]
------------------------------
From: "tiwolf" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Wed, 16 Feb 2000 12:07:11 -0800
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.
Johnny Bravo wrote in message ...
>On Tue, 15 Feb 2000 00:24:02 -0800, "tiwolf" <[EMAIL PROTECTED]> wrote:
>
>>I don't care about prime numbers,
>
> So your opinion is "anything is possible for the government, even those
>things which are impossible." Let me guess, you are posting from
>misc.survivalism, and you think the government has unlimited godlike
>powers.
> You've already admitted that you don't have a single clue about the
>topic under discussion. Why you feel this makes your opinion more
>informed than actual fact is beyond me. You should have quit while you
>were ahead.
>
> Johnny Bravo
>
------------------------------
From: Erik <[EMAIL PROTECTED]>
Subject: RSA Speed
Date: Wed, 16 Feb 2000 15:23:45 -0500
I wrote a program to do RSA with a 1100 bit modulus. I use 65537 for
the public key exponent, and the private key exponent is, of course,
near 1100 bits. It works, and encrypting with the public key takes
about a quarter of a second, but decrypting with the private key takes
43 seconds on a 400 MHz Pentium. Does this seem right?
Erik
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: EOF in cipher???
Date: Wed, 16 Feb 2000 13:47:27 GMT
[EMAIL PROTECTED] wrote, in part:
>Question is: What do most algos do when the output is going to be EOF?
> Example say I do some bit shifting, xoring etc and I'm outputing the
>encrypted results to a file. If one of the chars in the stream when
>encrypted happens to be EOF (Ascii #26) then when my program reads it
>back in for Decryption it stops at that character.
The algorithms don't do anything. You can use options when you open
the file to stop this from happening, or you can convert the pure
binary output to printable characters only by putting only 6 bits in
each printable character (for example), a process known as "armor".
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "BBC-Igor" <[EMAIL PROTECTED]>
Subject: multi-precision integer C library
Date: Wed, 16 Feb 2000 16:06:56 -0500
Can anyone point me in the right direction of a well-documented multi-precision
integer arithmetic C library?
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Question about OTPs
Date: Wed, 16 Feb 2000 16:09:44 -0500
As we all know, many people are becoming interested in one time pads due
to their "perfect" security system. Yes, while this system is perfect
with totally random data and a "perfectly" secure way to transfer the
pad-file, this is rare to come by.
Many people attempt to pack CD-ROM's with totally random data; however,
then you must tell your recipient which offset to start reading the pad
from. So, my question is this: for one message, so that I start at the
30,567,890 byte and the next I start tat the 30,567,889. While this is
only one byte off, the ciphertext is totally different; however, how
secure is this?
(A+K)-(B+K)=A-B
While most of the padding is identical, will pushing the offset back one
byte still aid cryptanalysts in cracking the message? I plan on writing
an OTP program in Python, which will take the path to the pad-file, the
starting offset, plaintext path, and ciphertext path and perform all of
this for you. Why Python? I don't know. Never used it before, I
figure that this will be a rather simple thing to do, yet remain
portable. I'm going to use the Windows toolkit so I can build a
stand-alone Windows executable; however, the heart of my program will be
extremely portable to other systems. Any suggestions on the program and
the security of the above problem?
--
Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Wed, 16 Feb 2000 19:58:34 GMT
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.
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: Hardware crypto device
Date: Wed, 16 Feb 2000 16:15:19 -0500
[EMAIL PROTECTED] wrote:
> Can anyone help me with this? (probably)
> Where can i find info on PCI / ISA crypto cards?
>
> please reply by mail.
>
> best regards
> thomas
Search deja.com for one of my posts. I had posted a link to a add-on
card that speeds up cryptographic procedures for online vendors.
Rainbow card or something to that effect.
--
Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: Albert P. Belle Isle <[EMAIL PROTECTED]>
Subject: Re: New standart for encryption software.
Date: Wed, 16 Feb 2000 16:22:12 -0500
Reply-To: [EMAIL PROTECTED]
On Wed, 16 Feb 2000 01:52:03 GMT, Boris Kazak
<[EMAIL PROTECTED]> wrote:
>
>And still the old adage is true: You keep your source code secret
>only if you are ashamed of it. Sic!
>
>Best wishes BNK
Which is, of course, the real business purpose of Non-Disclosure
Agreements.
NDAs allow a company which has borrowed other people's savings (on the
promise of providing a return on the investment) to legally protect
their code (integrated circuit design, whatever) while still enabling
outside second-, third- or whatever-number-parties to perform
professional evaluations (also for money, but paid by customers or
prospective new investors worried about not spending _their_
shareholders' money on snakeoil).
All of which, however, still doesn't make source code review capable
of catching all types of cryptosystem spiking. It just allows this
necessary (but not _sufficient_) part of due diligence to be performed
in spite of claims of "that's proprietary."
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE with
Forensic Software Countermeasures
http://www.CerberusSystems.com
================================================
------------------------------
Subject: Re: Does the NSA have ALL Possible PGP keys?
From: drickel <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp,misc.survivalism
Date: Wed, 16 Feb 2000 13:55:42 -0800
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).
However, you do have a point. Most any code can be broken. It's
just a matter of how many fingernails or toenails have to be
pulled off first. And if i don't want to pull off fingernails,
it shouldn't be that hard to plant a bug in your keyboard.
david rickel
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Mark VandeWettering <[EMAIL PROTECTED]>
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Wed, 16 Feb 2000 13:54:26 -0800
tiwolf 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.
It was in the medieval alchemist's best interest to turn lead into gold, but
somehow that never happened.
Unfortunately, even governments are subject to the limits of physical laws,
at least in the long run. It is equally unfortunate that it is cheaper and
more effective just to torture whatever information you need out of people than
to spend the money to crack their codes.
Mark
--
Mark T. VandeWettering Telescope Information (and more)
Email: <[EMAIL PROTECTED]> http://raytracer.org
------------------------------
** 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
******************************
