Cryptography-Digest Digest #979, Volume #9 Tue, 3 Aug 99 13:13:03 EDT
Contents:
Re: Storing keys ([EMAIL PROTECTED])
Re: the defintion of Entropy ("Douglas A. Gwyn")
Re: (Game) 80-digits Factoring Challenge (Johnny Hazard)
Re: Virtual Matrix Encryption ("Douglas A. Gwyn")
Re: A most useful cipher (wtshaw)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
("James Curran")
Re: A most useful cipher ([EMAIL PROTECTED])
Re: Is breaking RSA NP-Complete ? (Anton Stiglic)
Re: Americans abroad/Encryption rules? (wtshaw)
Re: Prime number. (Anton Stiglic)
Question about Information Theory (Coms 1003)
Re: With all the talk about random... (John Savard)
Sufficiently Random numbers (vincent)
Re: [Q] Why is pub key cert. secure & free from spoofing? (Michael Slass)
Re: Modified Vigenere cipher (John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Storing keys
Date: Tue, 03 Aug 1999 13:32:28 GMT
In article <[EMAIL PROTECTED]>,
Atle Sandvold <[EMAIL PROTECTED]> wrote:
> What is the best way of storing keys for a symmetric algorithm?
>
> If for instance users homedirs should be encrypted, and all the
> encryption keys should be stored in one safe place. The key to one
> particular homedir should be released when the user logs in.
You could encrypt the symmetric key using a password. Just hash the
password then encrypt the symmetric key. You don't need to store the
2nd key anywhere.
> If the key database is encrypted, some sort of master key would have
to
> be used to decrypt them. How should one store the master key?
See www.counterpane.com for their password safe program. What they did
is encrypted a database of your passwords (that you add) then to get
access to the list just use one main password. This way each app will
have their own password that you need not rememeber. It's at least as
safe as min(user password, hash+blowfish).
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: the defintion of Entropy
Date: Tue, 3 Aug 1999 14:56:26 GMT
Patrick Juola wrote:
> If he wants to call an aperiodic sequence a sequence of infinite
> period, why not let him?
If he wants to call blue "deep red", why not let him?
Because it is an incorrect application of established terminology,
that's why.
------------------------------
From: [EMAIL PROTECTED] (Johnny Hazard)
Crossposted-To: sci.math
Subject: Re: (Game) 80-digits Factoring Challenge
Date: 3 Aug 1999 15:17:43 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 28 Jul 1999 08:50:44 -1000, <[EMAIL PROTECTED]> wrote:
>kctang wrote:
>> Dear all,
>> Please factorize the 80-digits number:
>> 256261430091697968103677033465028955910<continue at next line>
>> 15360341017076023809547878443033203276429
>> Thanks & Bye, kctang
>There are 3 factors
>74681239503223976540012391
>73935890729093478299508777
>10094892705484334775926633
>This was factored with the Quadratic Field Seive using
>a pocket calculator in 163 minutes. The program is
>available for $199.
So i know i'm never gonna buy such calculator!
Your three "factors" a,b and c:
a*b*c = 408246186006833348959825664719124648220
666886045554299649802819054722602718039
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Virtual Matrix Encryption
Date: Tue, 3 Aug 1999 14:55:12 GMT
[EMAIL PROTECTED] wrote:
> DES for example was thought to provide 56-bit key strength until
> differential analysis broke all 16 rounds ...
What, pray tell, is "56-bit key strength"?
DES has not been publicly reported as broken in practice with
anything other than brute-force search of the key space. The
so-called "differential cryptanalysis" is not a practical attack.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: A most useful cipher
Date: Tue, 03 Aug 1999 09:38:05 -0600
In article <7o6o0k$35ag$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> Maybe having a varible number of character sets with automatic word wrap
> would be the way to go. You could write your messae and then pass it through
> a special program that would show you what it looks like ( or check format) to
> guarantee that only a certain subset of characters are used.
This is a sense is what I do in these programs, making the encryption more
or less semiautomatic The text is read from a file, pasted in, or written
in the built-in text editor. Beyond that, most use a preformatting
command that results in filtered blocks with obvious character changes.
Being block ciphers, you should pad out the last block if needed. The
block sizes are either obvious by looking a other blocks, and/or explained
in a legend. Also in the menu for use in backtracking to plaintext is the
postformat command. They are pretty slick in the way they work.
Another character set thing revolves around what characters are needed for
representing the keys, so you need to include at minimum those required,
and if you are making two or more keys at a single command, the whole
combined character set must be allowed to make any and all of them. Often
these sets are at least partially reflective of the actual sets used in
the encryption algorithm. By following these guide lines, keys can be
made directly from their own representations or from text in general. I
call this method of key generation THF, for transparent hash filter; the
results all each a permutation of one sort or another.
>... The varable
> number of characters needs to be just a list in a data file. But that varible
> data file can be used with an adaptive headerless huffman compression to
> produce the high entropy file.
>
> a file that could be encrypted by any means possible.
>
>
> David A. Scott
> --
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> http://www.jim.com/jamesd/Kong/scott19u.zip
> http://members.xoom.com/ecil/index.htm
> NOTE EMAIL address is for SPAMERS
--
MY lock, MY key.
------------------------------
From: "James Curran" <[EMAIL PROTECTED]>
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a
Byte?)
Date: Tue, 3 Aug 1999 09:49:56 -0400
Crossposted-To: alt.comp.lang.learn.c-c++,comp.lang.c++,microsoft.public.vc.language
O. Y. Realmink wrote in message <[EMAIL PROTECTED]>...
>Yeah right, and I have a Pentium with 64 megaoctets of ram and a 7
>gigaoctet hard drive. Give me a break, huh?
Read the side of a box of floppy disks. It usually lists the size as
"1440 kilobytes / 1440 kilo-octets" The term is actually quite popular
outside of the USA.
--
Truth,
James [MVP]
http://www.NJTheater.Com -and-
http://www.NJTheater.Com/JamesCurran
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: A most useful cipher
Date: Tue, 03 Aug 1999 13:49:13 GMT
In article <7o4agq$13l2$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> It seems like all you are doing is a form of compression which in
itself
> is a good idea so the the "entopy/bit" of the message increases. The
next
> step after this entopy increase would be to encrypt the message.
> Have you compared this to dynamic huffman compression. You can get
> one it my site. Or if your limiting the message to some fixed number
of
> printable characters and the spce and the "new line" and "double new
line"
> You could make the starting tree of the dynamic huffman only use X
number
> or character ( symbols). May methods all currently use all 256
symbols for
> all combinations of 8 bits. But there is no reason that much smaller
subset
> could be used.
> I could write such a linited one for you because if I limit the
subset of
> symbols used it would greatly increase the "entropy per bit". If the
users
> of "sci.crypt" can come be with such a subset. The smaller the subset
> the better. The big advantage of this type of compression for a first
pass to
> encryption is that if a message is intercepted and the "enemy" uses a
wrong
> key he will get a compressed file that when uncompressed will contain
> onlt the subset of synbols used and there are more apt to be false
messages.
> However I for one would not like to see the "new line or double new
line" as
> a symbol in the subset beause it is easy to make a reader program
that does
> line wrapping so why waste a symbol for it.
> Is there any one interested in this idea for compression. The user
is still
> free to pick the encryption method of his choice. It just would be
nice that
> as a first pass before encryption we could use a common method to
greatly
> increase the entropy of the message with out using a compression that
> has headers or is not "one to one".
#1 you don't need to compress the file to increase security.
Proof #1, consider the OTP.
#2 compression should be used only to decrease the message size. If
you have to uuencode the message you will be forced to increase the
messge size 25%. Wondering why it shouldn't be used for crypto? see
point #1
#3 encryption should be used to randomize the input as a function of
the input and private key. This should provide the 'randomization'
part of the message (i.e encipherment).
The security of a data packet should be considered aside from which
compression lib you used. If you used ZLIB for example well I just
have to learn the first part of the stream, then the adjacent parts are
just as easy as the first part (after guessing the plaintext). You
could use 'private' dictionaries for the compression method, but who
says your dictionary won't kill compression and make it blaintly
obvious that it was a bad dictionary and that literals were stored?
I think the two ideas go hand in hand when sending/getting packets of
encrypted data. But not in the security model. The security model
already contains a lot (key generation, encryption, etc...) to worry
about.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Is breaking RSA NP-Complete ?
Date: Tue, 03 Aug 1999 06:28:45 -0400
Here are the definitions (You can check them out in the Big Green Book,
I prefer other definitions,
using the notion of
non-deterministic machines instead of certificats,
but this book is more
available to people in this news group (if I am not mistaken...))
def. (NP) The complexity class NP is the set of all decision problems for
wich a YES
answer can be verified in polynomial time using some
extra information,
called a certificate.
def. (NP-Complete)
A desicion problem L is said to be NP-complete if
(i) L is in NP, AND
(ii) L_1 can be reduced, in polynomial time, to L,
for every L_1 in NP
The intuition of saying that a problem L_1 can be reduced, in polynomial time,
to L, is
to say that if I could solve problems from L, then if I have a problem from
L_1 to solve,
I just have to reduce the L_1 problem to L ,
solve that problem with a certificat, and get the answer to the L_1 problem
in polynomial time (polynomial reduction + polynomial using certifical for L).
Beeing able to do this for any problem L_1 in NP, means that if L could
be resolved in Polynomial time without a certificat, I could resolve all the
problems
in NP without a certificat.
def. (NP-Hard)
A problem (any problem, no just a decisional problem
(important distiction))
is NP-hard if the existence of a polynomial -time
algorithm for its solution implies
that P = NP.
The intuition to this class resides explicitly in the definition.
example of NP-Hard:
The SUBSET_SUM_D decisional problem (a specific instance of the KNAPSACK_D
problem) is the following:
given a set {a_1, a_2, ..., a_n} of positive integers and a positive integer
s, determine whether or not there is
a subset for wich the elements sum to s.
SUBSET_SUM_D is in NP-Complete
The computational version SUBSET_SUM_C, in wich you have to come up with the
subset that sums up to
s (and not just state that it exists), is in NP-Hard.
Anton
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Americans abroad/Encryption rules?
Date: Tue, 03 Aug 1999 09:53:51 -0600
In article <wgu20.933677090@riemann>, [EMAIL PROTECTED] (W.G.
Unruh) wrote:
>
> (A) The access control system, either through automated
> means or human intervention, checks the address of every
> system requesting or receiving a transfer and verifies that
> such systems are located within the United States or
> Canada;
Of course, if you hand someone a disk, you know where you are.
>
> (B) The access control system provides every requesting or
> receiving party with notice that the transfer includes or
> would include cryptographic software subject to export
> controls under the Export Administration Regulations, and
> that anyone receiving such a transfer cannot export the
> software without a license; and
That could be shrink-wrapped with a product.
>
> (C) Every party requesting or receiving a transfer of such
> software must acknowledge affirmatively that he or she
> understands that the cryptographic software is subject to
> export controls under the Export Administration Regulations
> and that anyone receiving the transfer cannot export the
> software without a license. BXA will consider
> acknowledgments in electronic form provided that they are
> adequate to assure legal undertakings similar to written
> acknowledgments.
Do you figure this applies to physical transfer as well? It seems rather
stupid to require ID and a signature from a person standing there before
you. Records, I have no records of who got what, never kept them
intentionally for that purpose, lost lots of such information somehow
during the course of events. Of course, I have never knowingly exported
any crypto items myself.
As crypto is of varied strengths, surely something like ROT13 is beyond
any serious control regulations?
--
MY lock, MY key.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Prime number.
Date: Tue, 03 Aug 1999 06:52:42 -0400
That response was completly out of track for crypto purposes..
First of all, if you are using primes that can fit in a double, it is not a
big enough prime,
you need special types, see SSLeay for example. Even if you choosed a prime
p, say,
50 bits, that could be secure to some extent, you will surely have to
compute some
values on that, say exponentiation p^2, and then your value explodes
Secondly, to test if a number is prime, you don't use the technic mentioned,
don't _ever_ use
that technic if you are using big primes (wich you will _always_ be using in
crypto).
See the posts under the section: Re: Q: Does ElGamal requie...)2 is also
prime like DH?
We talked about some stuff usefull for getting a prime number, some refs are
there.
Anton
"John McDonald, Jr." wrote:
> On Tue, 03 Aug 1999 10:15:52 +0800, Teh Yong Wei <[EMAIL PROTECTED]>
> wrote:
>
> >I have writing a simulation of elliptic curve cryptography. Can anybody
> >tell me that what is the best algorithm to generate random prime number
> >and why? Then, what is the most efficient way to prove that it is really
> >a prime number?
>
> As far as generating a random prime, you'll need someone elses
> response, but the fastest way to test a prime involves having all the
> primes less that the square root of your prime number. (So what
> you'll need to do is generate the first Z primes.)
>
> Anyways, to prove that it is really a prime number, you do this...
>
> Psuedo C-code...
>
> int myRandomNum =(Some Random Integer less than primes[Z]*primes[Z];)
>
> bool stillPrime = true;
> int primes[Z]; // Filled with Primes
> int squareRoot = (int) sqrt(myRandomNum);
>
> .
> .
> .
>
> while ((primes[x] < squareRoot) && (stillPrime))
> {
> if (myRandomNum % primes[x] == 0)
> stillPrime = false;
> else
> x++;
> }
>
> if (isPrime)
> cout << "Yep... Its Prime..." << endl;
> else
> cout << "Nope, what now, chief?" << endl;
>
> In all actuallity, these should all be doubles or better...
>
> Hope this helps!
>
> [-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-]
> John K. McDonald, Jr. Alcatel, USA
>
> [EMAIL PROTECTED]
> please remove -delete- for responses.
> --
> "I speak for me and not this company"
>
> TO SPAMMERS:
> Please view the definitions for
> "telephone facsimile machine,"
> "unsolicted advertisement," and the
> prohibition and penalty for sending
> unsolicited faxes before sending Un-
> solicited Commercial E-mail to the
> above address. Violators WILL BE
> PROSECUTED. These can be found
> in:
>
> The Telephone Consumer Protection Act
> of 1991, Title 47, Chapter 5,
> Subchapter II, Section 227.
> [=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=]
------------------------------
From: Coms 1003 <[EMAIL PROTECTED]>
Subject: Question about Information Theory
Date: Tue, 3 Aug 1999 11:54:10 -0400
Say we have a certain number of independent sources transmitting symbols,
each source with its own set of symbols and probability distribution
(memoryless). Each source has an associated entropy H_1, ..., H_n.
The question is this: does it follow directly from information theory
that, given any encoding of the symbols of the sources into binary,
transmission of one bit cannot reduce the entropy by more than one? That
is, if one bit is transmitted, giving new entropies H'_1, ..., H'_n, is it
not true that
H_1 + ... + H_n - H'_1 - ... - H'_n <= 1 ??
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: With all the talk about random...
Date: Tue, 03 Aug 1999 16:44:20 GMT
[EMAIL PROTECTED] wrote, in part:
>> Real random numbers are produced by rolling dice or equivalent
>> methods.
>Those are not random either. Consider physics your algorithm...
Ah, but where does the seed come from?
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: vincent <[EMAIL PROTECTED]>
Subject: Sufficiently Random numbers
Date: Sun, 01 Aug 1999 02:08:52 +0100
Hi guys,
I am currently developing a RSA keys generation prog.
I have everything BUT a good random generator (assuming the one in C is
not good, which is a pretty straightforward assumption).
My questions are :
Can I use a Pseudo-random generator (PRG) or a Real random generator
(RRNG, like a device).
If I can use a PRNG, then which one is better to use, where can I find
the algorithm or the C++ code to do it, how do I initialise the seed and
when do I initialise it.
If I have to use a RRNG, where can I find one (buy one or how do I write
one).
I've heard about one which could use the variation of a disk drive
motor's speed caused by Air turbulence.
I really need a good Random number generator (cryptographically secure
as well as quick) to generate a lot of keys.
Thanks for any answers (practical if possible).
------------------------------
From: Michael Slass <[EMAIL PROTECTED]>
Subject: Re: [Q] Why is pub key cert. secure & free from spoofing?
Date: Tue, 03 Aug 1999 08:33:07 -0700
Jerome:
You are absolutely correct that an active adversary can interpose himself
between you and anyone who is sending you a public key, and insert his own
key instead. The short answer to this problem is this:
At some point, you must be able to verify through a TRUSTED channel, (ie
not just the Internet) that the public key purported to belong to some CA
actually does. In the browser world, this is done by shipping a series of
certificates belonging to commercial Certification Authorites (like Thawte
and Verisign) with your browser.
Once you have these certificates, then you can trust that the public keys
on these certificates belong to the CAs as claimed, because you got them
through a trusted channel. From that point on, you can choose to accept
only those additional keys that have been signed by one of the CAs. You
can verify that the CA actually signed the key, because you have their
public key, and you trust it.
Make sense?
-Mike
Jerome Mrozak wrote:
> I'm a rank newbie, passing thru security issues for the 1st time. I've
> been exposed to the public key method, and an explanation showing
> host-spoofing:
>
> A --> Spy --> B,
>
> where B believes the public key it received is from A when it is really
> from Spy.
>
> My text claims that use of a public key certificate authority (CA) will
> keep the spy at bay. My question is: if the Spy can insert itself
> between A & B, why not between A & CA, or B & CA?
>
> Jerome.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Modified Vigenere cipher
Date: Tue, 03 Aug 1999 16:48:11 GMT
[EMAIL PROTECTED] (Castover80) wrote, in part:
>I'm still trying to find some of the crypto stuff that has been recently
>declassified. The NSA site gives a huge list of what has been turned
>over to archives, but those documents don't seem to be available on-line
>at NARA yet.
It's unlikely that the documents will be available on-line, since
they'd have to be available in the form of images. The National
Archives has a big budget, but it's not that big that they can make
all their documents available on-line.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
