Cryptography-Digest Digest #903, Volume #9 Sat, 17 Jul 99 21:13:03 EDT
Contents:
Re: Canadian Crypto ([EMAIL PROTECTED])
Re: randomness of powerball, was something about one time pads (Jerry Coffin)
Diffie-Hellman ([EMAIL PROTECTED])
Re: Diffie-Hellman (DJohn37050)
Re: NBE: Not crackable by brute force key search (SCOTT19U.ZIP_GUY)
Re: A few qustions on encryption (SCOTT19U.ZIP_GUY)
Crypt FAQ Comments : New Topics (David A Molnar)
Xor Redundancies ([EMAIL PROTECTED])
Re: A few qustions on encryption (John Savard)
Re: SkipJack source??? (John Savard)
Free chapters from Handbook of Applied Cryptography (Alfred John Menezes)
Re: Xor Redundancies (JPeschel)
Re: NBE: Not crackable by brute force key search (John Savard)
Re: Xor Redundancies ([EMAIL PROTECTED])
Re: A few qustions on encryption (Jerry Coffin)
Re: How Big is a Byte? (was: New Encryption Product!) (wtshaw)
Re: Diffie-Hellman (Tom McCune)
Re: NBE: Not crackable by brute force key search (wtshaw)
Re: Diffie-Hellman (Jerry Coffin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Canadian Crypto
Date: 17 Jul 1999 18:09:58 GMT
Daniel Urquhart <[EMAIL PROTECTED]> wrote:
> Check out
> http://www.efc.ca/
you might also want to check out:
http://crypto.yashy.com
--
Robert Guerra <[EMAIL PROTECTED]>
WWW Page <http://www.interlog.com/~rguerra/www>
PGP Keys <http://www.geocities.com/CapitolHill/3378/pgpkeys.html>
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: randomness of powerball, was something about one time pads
Date: Sat, 17 Jul 1999 08:40:40 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Jerry Coffin wrote:
> > /* pay to play the game
> > */
> > money --;
> > ...
> > /* check for matches
> > */
> > for (i=0; i<num_dice; i++)
> > if ( dice[i] == pick)
> > money++;
>
> Obviously one expects to lose half a buck per play that way.
> Try
> money = 0;
> for ( i = 0; i < num_dice; ++i )
> if ( dice[i] == pick )
> ++ money; /* payoff for this die */
> if ( money == 0 )
> -- money; /* you lose your bet */
>
> I also don't vouch for the uniformity of your 0..6 generator,
> but that's a relatively minor issue compared to the above.
If you look, you'll find that what you've just posted bears no
relationship with the description that was originally posted. If you
think about it, you'll immediately realize that it also bears no
relationship with any game ever played at any bazaar, carnival, etc.,
EVER.
The first rule of any such game is that you ALWAYS pay before you can
play the game. After you pay, if you get lucky, you might get money
back, but there's never, ever, any set of circumstances under which
you're allowed to play a game without paying. In direct contrast to
this fundamental rule, you're only asking the player to pay after he's
played, and then only if he didn't end up winning anything when he
rolled the dice.
------------------------------
From: [EMAIL PROTECTED]
Subject: Diffie-Hellman
Date: Sat, 17 Jul 1999 15:10:00 -0400
I seem to be a bit confused...I have heard that Diffie-Hellman is a Key
Exchange Algorithm, and I have also seen it used in PGP as a public key
algorithm....so wich is it?
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Diffie-Hellman
Date: 17 Jul 1999 20:48:59 GMT
Both, it is a public-key-based key agreement algorithm.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NBE: Not crackable by brute force key search
Date: Sat, 17 Jul 1999 21:41:47 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>But surely, if any method of deciphering ends with the plaintext,
>regardless of how, the code itself is broken, even if only for this
>instance. Tom pointed out in an earlier discussion, any algorithm can be
>beaten by brute force, you just use the algorithm and churn the
>potential keys through it. So the only arbitrary factors in brute-force
>cracking are the time required for execution of the algorithm, the
>volume of possible keys and the level of access you have to the
>components of the encryption method.
>
>Just my tuppence,
>
>James
If the Tom your refering to is the young kid then be aware he knows very
little about actual encryption. A long time a go I put him in my kill file
after I found it was impossible to carry on any resonable disscussion with
him. But if you have a method of high entropy the fact is that when one
does a brute force search you can end up with more than one solution
(assuming you can even do the brute force seach) so that the brute
force seach in itself may not be good enough. The fact is that when one
encrypts only a small amout of messages with a hiigh entropy method
there is not enough information for the attacker to know what the encrypted
message was. Even if one had the time to look at all the resonable
candidates. However if one is using something like a low entropy AES
candidate then you might as well not encrypt if your hope is to prevent
the NSA from reading your messages.
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
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: A few qustions on encryption
Date: Sat, 17 Jul 1999 21:29:04 GMT
In article <[EMAIL PROTECTED]>, "Krishna Sawh"
<[EMAIL PROTECTED]> wrote:
>I took two text files (file1 and file2) both the same contain the
>same data and the same size (50k), but file2 has one byte which is
>different. I encrypted the both files with the same key, when I
>compared each byte of the encrypted files I found all but 300 bytes
>were the same, I was just wondering if an algorithm exist that
>would encrypt file2 and be 99% different?
>Would this be a good form of encryption, if an algorithm dose not
>exist, where would I start in writeing one?
>
>Krishna Sawh
>[EMAIL PROTECTED]
>
You could try scott16u or scott19u A one bit change in the input file
anywhere changes the whole encrypted output file with out changing
the length of the file. But it is more advanced than most of the token
methods discussed here so you will not get any positive disscussions
about it here. I say downlaod it and try it your self using your own tests.
Before the brain washed people who do most of the posting here try to
talk you out of it.
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
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Crypt FAQ Comments : New Topics
Date: 17 Jul 1999 21:10:10 GMT
Here's some suggestions for possible new topics (or expansions of old
ones) in the sci.crypt FAQ :
* How To Find "The Literature"
Not everyone knows that a wide technical literature for
cryptography exists. They will after reading part 10 of the FAQ. The
problem then is that not everyone has a technical library nearby.
Sections 4-34 through 4-36 of the FAQ at
http://www.faqs.org/faqs/ai-faq/general/part4/
offer advice on how to get copies of technical reports, dissertations,
and papers.
Since so many cryptographers post their papers, an explicit link to
a list of cryptographers would also be helpful.
* Quantum Computers
Came up here recently, came up at DEF CON, comes up in Scientific
American and its ilk -- it's a hot topic. Points a FAQ could cover :
* Shor's paper for factoring + discrete log
* why Shor's algorithms don't apply to all of NP
* Grover's algorithm, and what this means for block ciphers
* Reasonably current public engineering results
* pointers to the lanl quant-ph archives, the Oxford quantum
computation group, www.openqubit.org,
* Dynamical Systems, Fractals, and Encryption
Came up recently, with some suggestions as to where to look for
details and two proposed systems.
* The AES Process
* IEEE P1363
Both of these are great sources of information. Plus, by
the time the FAQ is finished, 1363 will (hopefully) be a standard.
* Information-theoretic security beyond one-time-pads
This page on "Secret Key Agreement by Public Discussion"
is useful -- http://www.inf.ethz.ch/department/TI/um/keydemo/
as a relatively concrete demonstration.
* Practical Chosen-Message and Chosen-Ciphertext Attacks
* Existential Forgery, Malleable Encryption, and Padding Schemes
* Expanded section on "provable security" against such attacks.
These three are motivated by the fact that implementing RSA or ElGamal
naively (or even not-so-naively!) will get you in trobule. Daniel
Bleichenbacher's attack on PKCS #1 v1.5 is an example. Could also
use the auction example or bit commitment as a situation where
malleability is bad.
* Random Oracles - what they are, how they're used, why they can be
controversial
Random oracles are used in the proof for OAEP, which is used for PCKS #1
v2.0 -- and the question has come up here.
* Basing Public-Key Cryptography Solely on P?=NP
If quantum computers are built, will we lose public-key cryptography
forever? Could cover average-case complexity, the fall of knapsack
cryptosystems in more detail, then give pointers to more recent things
like lattices.
* Low-exponent attacks on RSA and Lattice Cryptanalysis
Something along the lines of "Lattice Basis Reduction : A Tool For
The Cryptanalyst" by Antoine Joux and Jacques Stern, found
at http://www.dmi.ens.fr/equipes/grecc/Membres/joux/pub.html
from this page:
http://www.dice.ucl.ac.be./~fkoeune/LLL.html
Thanks,
-David Molnar
------------------------------
From: [EMAIL PROTECTED]
Subject: Xor Redundancies
Date: Sat, 17 Jul 1999 18:38:58 -0400
I realize that Xor Encryption is very redundant, and can be cracked very
easily. I was wondering if anyone knows of a program that will at least
analyze an Xor Encryption cipher text and show the redundancies for it.
I have looked for one unsucessfully.
Thanks.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: A few qustions on encryption
Date: Sat, 17 Jul 1999 22:45:27 GMT
"Krishna Sawh" <[EMAIL PROTECTED]> wrote, in part:
>I was just wondering if an algorithm exist that
>would encrypt file2 and be 99% different?
>Would this be a good form of encryption, if an algorithm dose not
>exist, where would I start in writeing one?
There are algorithms where file2 would be completely different, and
others where only one byte would be different.
Both kinds of encryption can be equally secure except for indicating
that two files are similar, which might leak information.
However, some of the algorithms in which "only one byte" would differ
include, as a precaution, a random starting point each time they
encrypt so that even if the same file is encrypted twice, with the
same key, the two resulting files will be completely different.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: SkipJack source???
Date: Sat, 17 Jul 1999 22:50:51 GMT
[EMAIL PROTECTED] wrote, in part:
>I thought that SkipJack was supposed to be a complete and total
>secret...and yet here it is:
>ftp://ftp.funet.fi/pub/crypt/cryptography/symmetric/skipjack/
It was declassified some time back, to make it easier for the
government to find the suppliers it needed for SKIPJACK based
hardware. (Incidentally, a skipjack is a kind of tuna, so SkipJack is
incorrect.)
A .PDF file describing the algorithm is available at NIST (warning:
it's bulky because it's a digitized photograph of a description that's
only a few pages long) and it's also described on my web site at
http://www.freenet.edmonton.ab.ca/~jsavard/co0405.htm
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Alfred John Menezes)
Subject: Free chapters from Handbook of Applied Cryptography
Date: 17 Jul 1999 22:17:07 GMT
As some of you may know, we recently made available 9 chapters
from our "Handbook of Applied Cryptography" for free download from
our web site: www.cacr.math.uwaterloo.ca/hac/
Our publisher, CRC Press, has generously given us permission
to place another 2 chapters on the site. We have just uploaded
Chapter 3 (Number-Theoretic Reference Problems) and
Chapter 8 (Public-Key Encryption).
We continue to negotiate with our publisher to have even more
chapters uploaded to the web site.
We hope that these chapters will be of use to people in their
cryptographic work and study. We hope that by making the chapters
available for free download, the book will be accessible to those
who cannot afford to buy it, and to those who may only have a
marginal interest in the material presented in the book. Any
comments in this regard are greatly appreciated.
- Alfred
==========================================================================
| Alfred Menezes | Email: [EMAIL PROTECTED] |
| Department of C&O | Phone: (519) 888-4567 x6934 |
| University of Waterloo| Web page: www.cacr.math.uwaterloo.ca/~ajmeneze |
| Waterloo, Ontario | Web page for Handbook of Applied Cryptography: |
| Canada N2L 3G1 | www.cacr.math.uwaterloo.ca/hac/ |
| Centre for Applied Cryptographic Research: www.cacr.math.uwaterloo.ca |
==========================================================================
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Xor Redundancies
Date: 17 Jul 1999 23:22:18 GMT
>[EMAIL PROTECTED] writes:
>I realize that Xor Encryption is very redundant, and can be cracked very
>easily. I was wondering if anyone knows of a program that will at least
>analyze an Xor Encryption cipher text and show the redundancies for it.
>I have looked for one unsucessfully.
You could write code that first uses a Kasiski or IOC test to
determine the length of the repeated key. Then icorporate
a function to do a frequency analysis of each alphabet.
The most freqent character in a computer generated
text file should be 0x20. Write a function that finds
the offset of that character between plaintext and the
ciphertext and you have a cracker.
If you want a cracker that does all of that for you,
you'll find "Vcrack" as well as other tools on my
site.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NBE: Not crackable by brute force key search
Date: Sat, 17 Jul 1999 22:47:30 GMT
"User" <[EMAIL PROTECTED]> wrote, in part:
>In this case, having
>output same as input would certainly limit the uncertainty of numeric
>distribution, thereby increasing the likely hood of an attack based on
>known values and patterns.
Unless the input is very short, having the output the same size as the
input - except for fixed overhead, including such things as a random
IV - is not an undesirable property. It helps to reduce the
opportunity for certain forms of hanky-panky, among other things.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Xor Redundancies
Date: Sat, 17 Jul 1999 19:38:53 -0400
Thank you. I think I'll pass on Vcrack though...I think I'll learn more by
doing this myself.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: A few qustions on encryption
Date: Sat, 17 Jul 1999 10:06:03 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
net.com says...
> I took two text files (file1 and file2) both the same contain the
> same data and the same size (50k), but file2 has one byte which is
> different. I encrypted the both files with the same key, when I
> compared each byte of the encrypted files I found all but 300 bytes
> were the same, I was just wondering if an algorithm exist that
> would encrypt file2 and be 99% different?
> Would this be a good form of encryption, if an algorithm dose not
> exist, where would I start in writeing one?
Most methods of encryption work from the beginning of the file to the
end. The byte that's different may affect a few bytes before it (if
you use a block-oriented encryption) but will primarily affect the
bytes that come after it in the file.
If you're using a stream cipher, it's pretty much a given that the
changed byte will affect everything that comes after it in the file.
With block ciphers, it depends on how you use the cipher. It's
possible to encrypt each block completely separately from the others,
in which case your changed byte will only affect other bytes in the
same block.
There are also, however, various methods of chaining that can be used
with block-oriented encryption, any of which will propagate changes in
one part of the plain-text through all later blocks of cipher-textt
produced from it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Sat, 17 Jul 1999 18:38:57 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> wtshaw wrote:
> >
> > In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> I'm having a real hard time working out base zero arithmetic.
>
That's one option too many. Come, to think of it, base one is
noncomputational as well.
--
Encryption means speaking in turns.
------------------------------
From: [EMAIL PROTECTED] (Tom McCune)
Subject: Re: Diffie-Hellman
Date: Sun, 18 Jul 1999 00:09:46 GMT
=====BEGIN PGP SIGNED MESSAGE=====
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>I seem to be a bit confused...I have heard that Diffie-Hellman is a Key
>Exchange Algorithm, and I have also seen it used in PGP as a public key
>algorithm....so wich is it?
PGP uses ElGamal, or "the ElGamal variant of DH."
=====BEGIN PGP SIGNATURE=====
Version: 6.0.2ckt -Tom McCune PGP Pages: http://www.borg.com/~tmccune/PGP.htm
iQEVAwUBN5EbQ2R4bNCQMh9JAQHtGQf/Yxv00qbyJnG34+aIIOCynxpNxQigFB0m
NNoTB1f9D1yw8GSSx0GY0OQt8AErAfpU3SLIJv629+lk1NDsXMiBug9qcEMk10vS
TR7eTbe6l1lnbCe5sE+cPnw0kqltPCApvGH50CvM1NmQpTNrilzngPEq0prHhqeS
DejFAAe76iRLvy78UM3v1bdDg3l/YwO+pY9Hhosz0hPgxhfXlCzGQMuQA8xuw07u
JNAczdbV3Td97LjbM9vNk47gmoLbWWkPybq9CxfjfEtblTZSHYilth5fPbdkhinh
dOi09ZcHtA7p/CYRpaBdjBYKUJZCMv9ssY2c7uJjn4cQg+WLgwXSrQ==
=n/aB
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: NBE: Not crackable by brute force key search
Date: Sat, 17 Jul 1999 18:57:23 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> But surely, if any method of deciphering ends with the plaintext,
> regardless of how, the code itself is broken, even if only for this
> instance. Tom pointed out in an earlier discussion, any algorithm can be
> beaten by brute force, you just use the algorithm and churn the
> potential keys through it. So the only arbitrary factors in brute-force
> cracking are the time required for execution of the algorithm, the
> volume of possible keys and the level of access you have to the
> components of the encryption method.
>
There is nothing wrong in quantizing a keyspace. Seeing that it is too
big to brute force seems more important than leaving the option open that
there is a small keyspace. As far as doing simple work with different
bases, forging keys into the process, I think that I am on the right
track, not sure whereall the track can go, but chugging along still the
same.
Sure the stuff this fellow is pushing is a useful tool, but protocols for
use of a particular algorithm should include enough simplicity that you
can still use it if tired or somewhat drunk. Volunteers?
--
Encryption means speaking in turns.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Diffie-Hellman
Date: Sat, 17 Jul 1999 17:15:36 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> I seem to be a bit confused...I have heard that Diffie-Hellman is a Key
> Exchange Algorithm, and I have also seen it used in PGP as a public key
> algorithm....so wich is it?
PGP uses the PK encryption only for key-exchange. At least in recent
versions, the message itself is encrypted using IDEA.
------------------------------
** 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
******************************
