Cryptography-Digest Digest #272, Volume #9 Tue, 23 Mar 99 13:13:07 EST
Contents:
Detecting an Encryption/Decryption Algorithm. ([EMAIL PROTECTED])
Re: Random Walk (R. Knauer)
Re: Detecting an Encryption/Decryption Algorithm. ([EMAIL PROTECTED])
my crypto lib ([EMAIL PROTECTED])
RSA key distribution ("dino")
Re: Random Walk (R. Knauer)
Re: Symmetric vs. public/private (Bo D�mstedt)
Re: RSA key distribution (David A Molnar)
Re: Is TEA Algorithm safe???? ([EMAIL PROTECTED])
One-way hash for password ("Isaac Rajkumar")
Re: Basic OTP questions (R. Knauer)
Encryption and the Linux password files (Sundial Services)
Re: Basic OTP questions (R. Knauer)
Re: unicity, redundancy, and crypto help (Medical Electronics Lab)
Re: Basic OTP questions (Patrick Juola)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Detecting an Encryption/Decryption Algorithm.
Date: Tue, 23 Mar 1999 11:02:26 GMT
Hey,
Does anyone know of a program which is capable of detecting the algorithm
used in a simple encryption process when presented with the encrypted data,
the decrypted data and a key? I imagine such a program is possible and would
be quite useful. I am in such a situation, however, although I have the
decryption program it is 32 bit, with a 16 bit stub and over 102kb in size,
so quite difficult to debug/dissassemble. If anyone has experience with such
debugging, and would like to try and find the algorithm used, E-mail me and I
will send you the plain text, encrypted data, key and decryption program. I
know the algorithm is 32 bit, and the file size remains the same with the
addition of a 32 bit cheksum, so should be fairly simple. Your help would be
much appreciated, if you could, could you please E-mail a response as well.
http://www.sourceofkaos.com/homes/1nternal
1nternal's Virus Research & Development Outlet
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random Walk
Date: Tue, 23 Mar 1999 11:46:19 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 22 Mar 1999 17:37:59 -0800, "karl malbrain" <[EMAIL PROTECTED]>
wrote:
>MeThinks you've gone quite over the edge on this one
That's quaint - coming from you of all people.
>-- the very NATURE of
>the OTP is one of OBSCURING the plaintext under <<white>> noise XOR with the
>KEYSTREAM (or other LINEAR function).
Something far more fundamental than mere obscuring happens with the
OTP cipher. If you and your correspondent lose the key for a given
ciphertext, the message is lost forever. No matter how hard you try to
"find" the message, you will fail.
>Again, for sequences of question (e.g. all TEXT encoded under a
><<time-framed>> key stream, a statistical test over EQUIDISTRIBUTED
>group-wise ciphertext (to 24 bits is good enough for 1KK total text) would
>make any INDEPENDENT criteria fall-out.
Does anyone here understand what this poster just said?
>In other words, YOU'RE STILL NOT WORKING UNDER PRIORITIZATION!
Oh. Heaven forbid.
Bob Knauer
"Mistrust those in whom the impulse to punish is strong."
--Friedrich Nietzsche
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Detecting an Encryption/Decryption Algorithm.
Date: Tue, 23 Mar 1999 11:48:18 GMT
> Does anyone know of a program which is capable of detecting the algorithm
> used in a simple encryption process when presented with the encrypted data,
> the decrypted data and a key? I imagine such a program is possible and would
> be quite useful. I am in such a situation, however, although I have the
> decryption program it is 32 bit, with a 16 bit stub and over 102kb in size,
> so quite difficult to debug/dissassemble. If anyone has experience with such
> debugging, and would like to try and find the algorithm used, E-mail me and I
> will send you the plain text, encrypted data, key and decryption program. I
> know the algorithm is 32 bit, and the file size remains the same with the
> addition of a 32 bit cheksum, so should be fairly simple. Your help would be
> much appreciated, if you could, could you please E-mail a response as well.
Well no, a cipher shouldn't have detectable patterns in the ciphertext. That
would be really bad. Some cipher programs leave file headers, but that
doesn't affect the ciphertext.
BTW, any algorithm 'held in the dark' is not worth investigating. The person
who wrote it probably has no idea what they are doing, and don't want you to
know either.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: my crypto lib
Date: Tue, 23 Mar 1999 11:56:23 GMT
Some of you may already know that I am writing a free symetrical crypto
library. I have already implemtented 3 ciphers (RC4, TEA and TEAX) and
tonight I plan to add 2 or 3 more. It has a nice user interface, although
the API is not finished yet.
Basically I modeled the interface after C++, but I didn't want to use C++. So
for example to cipher with RC4 you would use:
Ciphers[RC4].encrypt(input, output, no_of_blocks, state);
(all of which is described in the package). So it's that simple. Of course I
want to write api for reading/writing text files (as binaries), and various
other routines.
Ok so why is Tom boring you with this? Well I have the structure for the
hashes and RNGs in place... One problem, I don't have any.
So I was wondering if anyone would be interested in helping. I could email
them what I have (source code, compiles with GNU C and TC) which is about 10KB
zipped. There are a lot of fixes todo before release. I still have to make
sure there are no endianess problems. For the first release I don't really
care about optimizations, just as long as the code works.
... Anyways, I can explain it in more detail if anyone wants to help.
Thanks,
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "dino" <[EMAIL PROTECTED]>
Subject: RSA key distribution
Date: 23 Mar 1999 10:31:50 GMT
Hi everyone
my customer asked me to assure him about uniform distribution of RSA keys.
Can anyone help me?
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random Walk
Date: Tue, 23 Mar 1999 13:01:17 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 22 Mar 1999 22:00:50 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>No. Confidence intervals measure the reposentativeness of a sample with
>respect to a population from which that sample is drawn. Neither the
>sample nor the population are assumed to be infinite.
>From Feller (p. 67):
+++++
"We shall encounter theoretical conclusions which not only are
unexpected but actually come as a shock to intuition and common sense.
They will reveal that commonly accepted notions concerning chance
fluctuations are without foundation and that the implications of the
law of large numbers are widely misconstrued. For example, in various
applications it is assumed that observations on an individual
coin-tossing game during a long time interval will yield the same
statistical characteristics as the observation of the results of a
huge number of independent games at one given instant. This is not so.
Indeed, using a currently popular jargon we reach the conclusion that
in a population of normal coins, the majority is necessarily
maladjusted."
+++++
>> Have you ever bothered to read Kolmogorov's critique of this issue?
>No. YOu have convinced me that would be a waste of time.
Now we see your position clearly. The wisdom of acknowledged experts
on these issues does not mean anything to you.
You are just a common bigot...
>No. See any introductory textbokk on statistics.
....and incredibly stupid at that.
Bob Knauer
"Mistrust those in whom the impulse to punish is strong."
--Friedrich Nietzsche
------------------------------
From: [EMAIL PROTECTED] (Bo D�mstedt)
Subject: Re: Symmetric vs. public/private
Reply-To: [EMAIL PROTECTED]
Date: Tue, 23 Mar 1999 13:24:22 GMT
Billy Cole <[EMAIL PROTECTED]> wrote:
>I currently have the need to incorporate encryption
>into an application. I've been doing a lot of reading
>and still can't come up with an answer as to whether
>to use the public/private key method or a symmetric
>approach. Assuming I have no requirement to conform
>to the public/private key method, what will I gain/lose
>using that approach?
...
>Billy
A correct, and also surprising answer to that question,
is published in (1) .
It doesn't matter if you use pubic key encryption
or symmetrical (secret key) encryption. You still have
to distribute the keys securely. To do that efficiently you
need a key distribution centre. The centre is called a key
signing authority if you use public key encryption .
Distributing a key securely is done by sending the key
locked inside a key loader (or other means).
Note that using public key encryption and not sending
any key by secure means (i.e. by a key loader) implies that
your network will be insecure. No one of all PGP-users
will ever admit that - and as this is a published fact I suggest
that you let your library provide you with a copy of the evidence.
Bo D�mstedt
Cryptographer
Protego Information AB
Generate your session keys the easy and secure way:
http://www.protego.se/sg100_en.htm
E-mail: [EMAIL PROTECTED]
Reference (1):
Kline, C.S. and Popek, G.J.
"Public Key vs Conventional Key Encryption"
AFPS Conference Proceedings,
Vol 48, 1979 NCC Pages 831-837
(c) 1979 by AFIP Press.
Reprinted by permission in
"Advances in Computer System Security"
by Rein Turn (editor) Chapter 6.2, pages 291-297
(c) 1981 by Artech House, Inc.
ISBN 0-89006-096-7
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: RSA key distribution
Date: 23 Mar 1999 14:36:24 GMT
dino <[EMAIL PROTECTED]> wrote:
> Hi everyone
> my customer asked me to assure him about uniform distribution of RSA keys.
> Can anyone help me?
wouldn't that depend on your random number generator and method of prime
generation? the fact that e*d === 1 mod phi(n) means that "only" numbers
relatively prime to n will be used as keys, but that is not much of a bias.
rather, you hope only numbers relatively prime to n are used as keys,
otherwise the number is p,q or a multiple of p or q.
if you're using the standard "generate random number, then run M-R tests
on it," then you probably want to ask whether some numbers are more likely
than others to pass the number of tests with the security parameters you're
using than others. I don't know the answer to that question.
maybe a place to start is Daniel Bleichenbacher's thesis, which seems
to include a discussion of many different types of primality tests
(just picked it up)
http://www.bell-labs.com/user/bleichen/diss/thesis.html
alternatively, you could look at other methods of prime generation (you'll
still need a decent random number generator) like Ueli Maurer's method,
described with implementation (and an optimization that makes it NOT
uniform) by Preda Mihailescu in
CRYPTO '94 with an eye towards producing one that's uniformly distributed.
there's also an article by Eric Bach in the SIAM Journal on Computing 17 no2
that may be useful. Some distillation of these methods is in the Handbook
of Applied Cryptography.
Thanks to the poster who pointed them out a few months ago...
-David Molnar
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is TEA Algorithm safe????
Date: Tue, 23 Mar 1999 13:43:38 GMT
> You're probably right: ISTR an attack of this sort; this is one of the
> attacks that didn't really worry me for most applications. (Thought there
> was another attack since, but I may be mistaken and it sure wasn't much
> more frightening.)
It was 2^23 plaintexts (8MB) and 2^32 effort. BTW, what does that mean!!!
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Isaac Rajkumar" <[EMAIL PROTECTED]>
Subject: One-way hash for password
Date: Tue, 23 Mar 1999 10:24:34 -0600
This is a multi-part message in MIME format.
=======_NextPart_000_0023_01BE7517.58C13FF0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello All -=20
=20
I am considering using a one-way hash (using MD5) along with 16 bits of =
salt as the means of storing passwords. Does anyone have any =
recommendations/comments regarding this. Since it is not possible to =
recover and migrate the passwords to a different scheme in the future, I =
would like to know if this is appropriate.=20
=20
What scheme did any of you end up using and why? Has some kind of a =
standard evolved in this regard?
=20
Thanks for any comments/suggestions.
=20
=20
Isaac
=======_NextPart_000_0023_01BE7517.58C13FF0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"><!DOCTYPE HTML =
PUBLIC "-//W3C//DTD W3 HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Hello All - </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>I am considering using a one-way =
hash (using=20
MD5) along with 16 bits of salt as the means of storing passwords. Does =
anyone=20
have any recommendations/comments regarding this. Since it is not =
possible to=20
recover and migrate the passwords to a different scheme in the future, I =
would=20
like to know if this is appropriate. </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>What scheme did any of you end up =
using and why?=20
Has some kind of a standard evolved in this regard?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT color=3D#000000=20
size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Thanks for any=20
comments/suggestions.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Isaac</FONT></DIV></BODY></HTML>
=======_NextPart_000_0023_01BE7517.58C13FF0==
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Basic OTP questions
Date: Tue, 23 Mar 1999 13:12:32 GMT
Reply-To: [EMAIL PROTECTED]
On 22 Mar 1999 18:17:01 -0600, "Tim Mavers" <[EMAIL PROTECTED]>
wrote:
>On that note, how does one know if you have the right message? I was
>always curious to know this after reading about Deep Crack and the other
>various brute-force attacks against DES. With the kinds of possible
>combinations they go through, how the heck do they know when they have found
>the right message? I am sure at some point, certain phrases may come up
>that appear to be legimate, where in all actuality, they are just anomolies
>generated by coincidence.
If the key is significantly smaller in length than the plaintext, the
possibility that a valid decryption is intelligible is negligible.
IOW, only one intelligible message is likely among all the possible
decryptions. This has to do with the concept of Unicity Distance,
which is covered in Schneier's main book.
For example for DES with its 56-bit key, the unicity distance is a
mere 8.2 ASCII characters. That means that any message significantly
longer than 8.2 bytes, only that message will be intelligible among
all the possible decryptions of the cipher. If the cryptanalyst has
access to a DES-cracker, he will find only 1 message among the 2^56
possible decrytions is intelligible - and he then concludes with
reasonable certainty that it is your intended message. Of course this
assumes that no pre-processing was performed on the message that would
destroy its intelligibility.
That's why it is crucial to use a key of the same length as (or longer
than) the plaintext if you want proveably security. Of course, you
cannot reuse the key either, if you want proveable security.
Bob Knauer
"Mistrust those in whom the impulse to punish is strong."
--Friedrich Nietzsche
------------------------------
Date: Tue, 23 Mar 1999 10:38:03 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Encryption and the Linux password files
I'm rather startled to find that Linux still uses a login password
scheme that is based on a publicly-available password file that is
easily replaced or substituted. Systems have been "taken over" in that
way.
I was wondering who has done something to replace that password-scheme
with a stronger system. It seems obvious to me that a public-key
cryptography system (for example) could be used to create a much
stronger authorization system -- e.g. using a password built in to the
kernel when it's built, and different for every computer -- which would
not only render password-files worthless if stolen, but would make it
impossible to "infect" the password file with records from another
source, or to substitute the password-file with one of your own.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Basic OTP questions
Date: Tue, 23 Mar 1999 17:43:33 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 23 Mar 1999 17:06:05 -0000, "burt" <[EMAIL PROTECTED]>
wrote:
>You can tell if a message is valid by doing some stats on the decrypted
>text. e.g. english will have an approx percentage of e's etc. so you have a
>profile for the whole language (e.g. every letter has a certain probablilty
>in English.)
If all possible intelligible messages are equally probable, as in an
OTP cipher, that procedure will not give you any reason to pick one
over the other.
Bob Knauer
"Mistrust those in whom the impulse to punish is strong."
--Friedrich Nietzsche
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: unicity, redundancy, and crypto help
Date: Tue, 23 Mar 1999 11:48:45 -0600
[EMAIL PROTECTED] wrote:
>
> Does anyone know of papers or articles (on the web or in journals) that
> address unicity and key redundancy with RSA, Eliptic Curve, ElGamal or DES?
> Or for that matter ways of analyzing unicity and key redundancy using
> methods other than what shannon came up with in "Communication Theory of
> Secrecy Systems"?
You've got 3 public key and 1 symmetric key algorithm listed. How
do you compare a dual key system with a single key system?
Just for my edification, what is "key redundancy"?
Thanks,
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Basic OTP questions
Date: 23 Mar 1999 09:00:31 -0500
In article <e3BJ2.37715$[EMAIL PROTECTED]>,
Tim Mavers <[EMAIL PROTECTED]> wrote:
>I just started reading Applied Cryptography and had some basic questions
>regarding OTPs. In the book, he says that in theory a OTP is the perfect
>encryption because as long as you have random numbers in your keys, it would
>be impossible to determine the message because the ciphertext could be
>deciphered to any phrase. Not knowing the phrase would make it impossible
>to tell if you had the right key.
>
>Now isn't this the case with most encryption algorithms? You really have to
>know what your looking for in order to find it, right?
>
>On that note, how does one know if you have the right message?
Bluntly, no, it isn't the case with most encryption algorithms.
Let's look at a very simple case -- a Caesar cypher.
The idea is that you offset each letter by a (fixed) constant --
so "attack" becomes (e.g.) "buubdl" or "cvvcem." There being only
26 meaningfully different offsets, there are only 26 possible plaintext
for a given cyphertext. The odds are good, and only get better with
increasing length, that there will only be one meaningful English
phrase among that set of 26. Or, for that matter, that there will
only be one meaningful phrase in ANY language among that set of 26.
This is closely related to the notion of the "unicity point," which
is informally defined as the amount of text it takes (for a given
system) such that you're unlikely to have more than one plausible
decryption. For a 26-key system (and English text), the unicity
point is less than two characters. For a more powerful system such
as DES, the unicity distance is still only about eight characters.
In other words, if you took a given 8-character cyphertext and tried
decrypting it with all 2^56 possible DES keys, you're likely to find
only one "English" message.
-kitten
------------------------------
** 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
******************************
