Cryptography-Digest Digest #787, Volume #12 Wed, 27 Sep 00 23:13:01 EDT
Contents:
Re: Tying Up Loose Ends - Correction (SCOTT19U.ZIP_GUY)
Non-Repudiation mechanism ("Kevin Crosbie")
Javascript SHA-1 Implementation (Cornelius Sybrandy)
Adobe Acrobat -- How Secure? ("David C. Barber")
Re: Chaos theory (David A Molnar)
Re: Chaos theory (Jim Gillogly)
Re: Non-Repudiation mechanism ("Lyalc")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Tying Up Loose Ends - Correction
Date: 28 Sep 2000 00:00:33 GMT
[EMAIL PROTECTED] (Bryan Olson) wrote in
<8qtter$pa6$[EMAIL PROTECTED]>:
>Tim Tyler wrote:
>> Bryan Olson wrote:
>
>> : Knowledge of the ciphertext is not enough. With no better
>> : attack than exhaustive search, you have to do a trial
>> : decryption, for each key, and those alone make the attack
>> : intractable.
>>
>> There are plenty of attacks where the ability to reject
>> keys is useful - even with no crypyanalytic attack on the
>> cypher.
>
>None of which are at issue. You claimed that knowing some
>number of bits of plaintext *normally* reduces the keyspace
>or "effective keyspace" by that many bits.
>
>> For example, information about the key used may be revealed by
>> deficiencies in the key-generation process.
>
>Unlike the known plaintext at issue, this would reduce the
>keyspace - there would be fewer keys to consider.
>
>> ...or partial information about they key used by be
>> leaked at either end - perhaps by capture of an enemy
>> agent's key pad.
>
>So things other than the known plaintext you noted may
>reduce the effective keyspace.
>
>
>> Finally, your lack of knowledge relating to cryptanalytic
>> attacks on the cypher should not lead you to believe that
>> your opponent doesn't have access to such an attack.
>
>Can known plaintext attacks break some ciphers? Sure. Now
>let's get back to the claim at issue. You didn't say that
>the effective keyspace is reduced provided you have a
>certain kind of known plaintext attack.
>
>You agreed that given a thousand bits of known plaintext
>your "effective keyspace" for 448 Blowfish is "probably very
>small, to the point of being practically non-existent." But
>your best attack takes time on the order of 2^448 and is
>completely intractable. That's exactly the effect we look
>for in a keyspace.
>
>
>--Bryan
>--
>email: bolson at certicom dot com
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
>
Most people interested in cryptography relize there
is more than one way to look at a cipher. Shannon was
found of looking at it from an information point of view.
That has to deal with weather an encrpytion has encough
information to be undone at all. Using bad compression reduces
the effective key space so much that there is only one
solution. Meaning from an information point of view it is
not good to use bad compression. Many modern ciphers have
no hope of being that secure. So they go with what they
help is time complexity. Meaning they the time to find the
solution is so large that they don't worry about the fact
they are usually not good ciphers from the Shannon information
point of view. However any good cryptographer unless he wants
to mislead people should know that it is best not to use a
cipher system that has enough information that it can be broken.
True for public key ciphers there is no choice one is stuck
with ciphers that contain enough information that they can be
broken given enough time. But that does not mean one has to
use general methods where the only valid key that works is the
key your using. Maybe you should read some of shannon's work
from the 40's. The problem of relying only on time complexity
is that history is litter with once million years to break ciphers
that get broken. The reason the OTP is safe is that there is not
enough information to break the system. One should strive to limit
any information that could be used to break it. Instead od saying
this is so complex it can't be broked since history will prove you
wrong.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: "Kevin Crosbie" <[EMAIL PROTECTED]>
Subject: Non-Repudiation mechanism
Date: 28 Sep 2000 00:23:50 GMT
Hi all,
I have been searching for a solution for performing cross-platform
non-repudiation for web-sites.
I have not been in the security field for long enough to know if this
solution is good enough, or if it has major flaws, so I decided to put it
into the public domain for feedback. This solution is similar to that
given by Baltimore's FormSecure signed applet system.
The System works as follows:
We have a Client Browser, a Web-Server, and a Certificatation
Authority/Registration Authority.
First of all, to use the Service I provide, the user must authenticate by
either a username/password, Browser Cert or Smartcard.
When the client goes to a certain page, they are requested to download a
signed-persistent applet. The applet on first load will generate an RSA
KeyPair, and a Certificate request. The Private key is stored, and the
Cert Request is posted to a servlet on the web-browser. The servlet will
check the request, and send it to an RA, which will automatically send this
on to the CA, who will sign the cert, return it to the RA, who will in turn
return it to the servlet.(Is this structure in place anywhere, I think
Unicert does this automatic process.)
Point: The cert doesn't tie to the user, as it was an automatic process,
using an ARM, or worse, nothing, the only thing I have is that the user
authenticated using their authentication mechanism, and that I can see the
generated cert at a time that they were authenticated.
On receipt of the CA signed cert, the servlet will save the cert(encrypted)
to a database, and return it to the applet (anybody know how long it takes
for the cert registration process to complete?) The applet will then save
this to a disk(password protected in a PFX file in the JVM
System.getProperty(" user.home") directory)
When a signature for non-repudiation takes place, the applet is called to
sign a piece of data, prompt the user for their password, and return a piece
of PKCS#7 data containing the signed data object, which is sent to the
servlet, timestamped and stored in the users account for arbitration in the
case of a dispute. Before the signature is stored, it is validated against
a CRL on the CA, and with the signing cert stored in the database, to make
sure it is still the cert first applied for, otherwise it is rejected.
That is the system. I can see one obvious point of attack:
Someone inside my company could apply for a new certificate using the same
automatic process, encrypt it, and store it, give the cert components
including the private exponent to the user. The user will authorize a
transaction which is supposed to be non-repudiable, and this validates ok,
and the signed data get's stored.
The insider replaces the origional encrypted cert. A dispute takes place
and we see, hey the signature certificate doesn't match that in the PKCS#7
object. Non-Repudiation fails.
Notes:
The user must authenticate with the authentication mechanism, thus, unless
this is also replaced, and a bogus user created, we can show that the user
had a part in this, or that their authentication mechanism was stolen by a
malicious party.
When a signature doesn't match in the arbitration process, we can tell
straight off that the system was tampered with.
Points:
1. Without smartcards being used exclusively, the is no way to say for sure
that the person is who they say they are.
2. We can make this system as secure as we can from an insider attack by
requiring smartcards to use database encryption/decryption functions which
are done through a Hardware Security Module.
3. The way that we are using the certs, a trail is left in the case of
tampering, showing us that the user was wither negligent, or fraudulent,
posing the question, would we be expected to take liability in the case of
negligence or fraudulence?
That is basically all I can say about the system. Please review this and
give me feedback. It is a solution, but I'm not sure if it is the best
solution.
Best Regards,
Kevin
------------------------------
From: Cornelius Sybrandy <[EMAIL PROTECTED]>
Subject: Javascript SHA-1 Implementation
Date: Wed, 27 Sep 2000 21:06:09 -0400
This is a multi-part message in MIME format.
==============890BC5BB006D53BF9CAE0D07
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Greetings all.
I've been doing some web design and I noticed a severe lack of
JavaScript code that hashes passwords. Out of boredom and experimenting
with JavaScript, I decided to create my own. I implemented a version of
SHA-1 in Javascript for the sole purpose of hashing passwords. There is
more information in the comments provided. I felt I should let this
application be reviewed by the group before releasing it to the world.
Anyway, have fun with it and let me know what you think.
csybrandy
==============890BC5BB006D53BF9CAE0D07
Content-Type: text/html; charset=us-ascii;
name="hashtestorig.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="hashtestorig.html"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Javascript Password Hasher</title>
</head>
<script language="Javascript">
/*********************************************************
Javascript Cryptographic Hash Function.
Created By Cornelius Sybrandy. ([EMAIL PROTECTED])
Copyright 2000, Cornelius Sybrandy.
This code was created to allow passwords to be hashed
before being transmitted across a network and stored.
Since this is done on the client, it is hoped that this
will minimize the risk of sending passwords online.
The algorithm will accept passwords up to 55 characters.
Uppercase/lowercase letters, numbers, and symbols are
accepted. The algorithm outputs a string of hexadecimal
values for easy storage in a database.
This algorithm is the SHA-1 hash algorithm as detailed in
the FIPS 180-1. No salts are used at this time due to
lack of secure random number generator. If anybody has
some Javascript code for one, I would like to include it
and will gladly acknowledge the contribution.
The 55 character limit is not a limitation of the algorithm,
merely a coding limitation to ensure simplicity. The
author feels that this is a reasonable decision since most
users normally use characters of 8-12 characters in
length.
This code has been tested in Netscape 4.7, I.E. 5.0, and
several Mozilla nighly builds.
This code is free for use so long as it includes this
header recognizing the original creator of this script.
The author does not claim responsibility for the misuse
or incorrect implementation of this script. The author
also claims no responsibility if any information is lost
or compromised due to coding errors or the insecurity of
the algorithm. At the time this script was developed,
the SHA-1 algorithm is considered one of the more secure
cryptographic hash algorithms and is the current
standard for government usage.
One last note: Thank you Netscape/Mozilla team for
having a Javascript console in your browsers. It makes
debugging a LOT easier.
*********************************************************/
var HexNumToChar = new Array("0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "a",
"b", "c", "d", "e", "f");
/* IV's/Constants for the algorithm */
var A = 0x67452301;
var B = 0xefcdab89;
var C = 0x98badcfe;
var D = 0x10325476;
var E = 0xc3d2e1f0;
/* Round constants */
var R1 = 0x5a827999;
var R2 = 0x6ed9eba1;
var R3 = 0x8f1bbcdc;
var R4 = 0xca62c1d6;
/* output of the hash function */
var fingerprint = new Array(5);
/* input string of words formatted for hash function */
var word = new Array(80);
/* Round 1 function */
function f1(b, c, d)
{
return ((b & c) | (~b & d));
}
/* Round 2 function */
function f2(b, c, d)
{
return (b ^ c ^ d);
}
/* round 3 function */
function f3(b, c, d)
{
return ((b & c) | (b & d) | (c & d));
}
/* round 4 function */
function f4(b, c, d)
{
return f2(b, c, d);
}
/* Rotate left function */
function rotateleft(x, y)
{
return ((x << y) | (x >>> (32 - y)));
}
/* Converts a 32 bit word to a hexadecimal value */
function ToHex(input)
{
return HexNumToChar[(input >>> 28)&15] +
HexNumToChar[(input >>> 24)&15] +
HexNumToChar[(input >>> 20)&15] +
HexNumToChar[(input >>> 16)&15] +
HexNumToChar[(input >>> 12)&15] +
HexNumToChar[(input >>> 8)&15] +
HexNumToChar[(input >>> 4)&15] +
HexNumToChar[(input & 15)];
}
/* Hash function itself. Outputs a 160 bit or 40 character hash/fingerprint */
function hash()
{
var i;
var temp;
var a = A;
var b = B;
var c = C;
var d = D;
var e = E;
for (i=0; i<20; i++)
{
temp = rotateleft(a, 5) + f1(b, c, d) + e + word[i] + R1;
e = d;
d = c;
c = rotateleft(b, 30);
b = a;
a = temp;
}
for (i=20; i<40; i++)
{
temp = rotateleft(a, 5) + f2(b, c, d) + e + word[i] + R2;
e = d;
d = c;
c = rotateleft(b, 30);
b = a;
a = temp;
}
for (i=40; i<60; i++)
{
temp = rotateleft(a, 5) + f3(b, c, d) + e + word[i] + R3;
e = d;
d = c;
c = rotateleft(b, 30);
b = a;
a = temp;
}
for (i=60; i<80; i++)
{
temp = rotateleft(a, 5) + f4(b, c, d) + e + word[i] + R4;
e = d;
d = c;
c = rotateleft(b, 30);
b = a;
a = temp;
}
fingerprint[0] = a + A;
fingerprint[1] = b + B;
fingerprint[2] = c + C;
fingerprint[3] = d + D;
fingerprint[4] = e + E;
}
/* Initialization function */
function init(text)
{
var i;
var count;
var bitcount = 0;
var diff;
var tempstring = text.value;
for (i=0; i<80; i++)
{
word[i] = 0;
}
count = 0;
for (i = 0; i < tempstring.length; i = i + 4)
{
diff = tempstring.length - i;
if (diff == 1)
{
word[count] = (tempstring.charCodeAt(i) << 24) ^
0x800000;
bitcount += 8;
}
else if (diff == 2)
{
word[count] = (tempstring.charCodeAt(i) << 24) ^
(tempstring.charCodeAt(i+1) << 16) ^
0x8000;
bitcount += 16;
}
else if (diff == 3)
{
word[count] = (tempstring.charCodeAt(i) << 24) ^
(tempstring.charCodeAt(i+1) << 16) ^
(tempstring.charCodeAt(i+2) << 8) ^
0x80;
bitcount += 24;
}
else
{
word[count] = (tempstring.charCodeAt(i) << 24) ^
(tempstring.charCodeAt(i+1) << 16) ^
(tempstring.charCodeAt(i+2) << 8) ^
(tempstring.charCodeAt(i+3));
word[count+1] = 0x80000000;
bitcount += 32;
}
count++;
}
word[15] = bitcount;
for (i=16; i<80; i++)
{
word[i] = rotateleft((word[i-3] ^ word[i-8] ^ word[i-14] ^ word[i-16]), 1);
}
}
/*********************************************************
This funcion may be adapted/modified/copied in order to
make it work in any specific application.
*********************************************************/
function HashOnChange(here)
{
init(here.form.password);
hash();
here.form.hashedpassword.value = "";
for (var i=0; i<5; i++)
{
here.form.hashedpassword.value = here.form.hashedpassword.value +
ToHex(fingerprint[i]);
}
}
</script>
<body>
<form action="">
<p>Enter a password here
<input type="text" name="password" size="20">
<input type="button" name="hashme" value="Hash" onClick="HashOnChange(this)">
<p>Here is your hashed password
<input type="text" name="hashedpassword" size="40">
</form>
</body>
</html>
==============890BC5BB006D53BF9CAE0D07==
------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Adobe Acrobat -- How Secure?
Date: Wed, 27 Sep 2000 18:10:54 -0700
I am looking to distribute some documents I don't want the user to be able
to alter or print. Acrobat was suggested, but IIRC, wasn't the Steven King
story distributed through Acrobat, and it was broken quickly just by loading
it into the full fledged Acrobat program?
*David Barber*
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Chaos theory
Date: 28 Sep 2000 01:52:17 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote:
> Soeren Gammelmark <[EMAIL PROTECTED]> wrote:
> : I was woundering if anyone ever thought about using chaos theory in
> : order to make cryptographic algorithms. [...]
> Chaos, by definition means "sensitive dependence on initial conditions".
> See Q.2.9 in the sci.nonlinear FAQ for more details:
> http://www.enm.bris.ac.uk/research/nonlinear/faq-[2].html#Heading12
I will, thanks. My initial reaction, however is "that's an expansive
definition and I would like to see something more precise."
> Practically all cryptography depends intimately on chaos. That's what
> "avalanche" relates to, for example.
OK. Now how the tools of "chaos theory" and the kind of "chaos" studied
there helpful for cryptography? Is there anything which as stated looks
likely to help us?
-david
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Chaos theory
Date: Thu, 28 Sep 2000 02:35:33 +0000
Tim Tyler wrote:
>
> Jim Gillogly <[EMAIL PROTECTED]> wrote:
>
> : It can be worse than this: because chaotic systems have attractors,
>
> "Having attractors" is neither a defining nor a necessary property of
> chaotic systems. For a definition, see the sci.nonlinear FAQ:
> http://www.enm.bris.ac.uk/research/nonlinear/faq-[2].html#Heading12
My understanding of chaos and attractors is more accurately
represented by this reference from the Mathematica people:
http://mathworld.wolfram.com/Chaos.html
A dynamical system is chaotic if it
1. Has a dense collection of points with periodic orbits,
2. Is sensitive to the initial condition of the system (so
that initially nearby points can evolve quickly into very
different states), and
3. Is topologically transitive.
Criterion 1 above is the property I was referring to that allowed
me to break a "chaotic" cryptosystem posted to sci.crypt and another
that wasn't.
> : In mathematics, however, chaos lies on the boundary between
> : order and disorder, and is a study of systems that have behavior
> : that's largely predictable statistically...
>
> Not necessarily correct - chaotic systems can be highly disordered.
Chaotic systems are predictable in the short term, and by the
Wolfram definition above exhibit periodic behaviors. Even short
term predictivity is anathema to cryptosystems, and periodic
behavior may be the kiss of death.
I don't rule out the possibility that a chaotic system can provide
good grounding for a strong cipher. None of the chaos-based
cryptosystems I've studied have been strong, though.
--
Jim Gillogly
Highday, 7 Winterfilth S.R. 2000, 02:24
12.19.7.10.11, 7 Chuen 14 Chen, Fourth Lord of Night
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Non-Repudiation mechanism
Date: Thu, 28 Sep 2000 13:54:47 +1000
Sigh...
What happens when a valid user gets 2 or more valid certificates (as per the
bogus cert attack described)?
Smartcards need a 'secure' reader that incorporates a keypad or biometric
entry device, especially if you want to move beyond an expensive duplication
of a password mechanism towards something that has some amount of legal
validity.
How does the RA know this will be a valid cert request?
Simply by duplicating all the validation mechanism at another location.
More procedures, more systems/services holding duplicate info 9or with
access to a master copy.
The management hassles of the above aren't worth it unless you're a
government dept which can bury losses for decades.
Lyal
Kevin Crosbie wrote in message <8qu32m$[EMAIL PROTECTED]>...
>Hi all,
>
>I have been searching for a solution for performing cross-platform
>non-repudiation for web-sites.
>I have not been in the security field for long enough to know if this
>solution is good enough, or if it has major flaws, so I decided to put it
>into the public domain for feedback. This solution is similar to that
>given by Baltimore's FormSecure signed applet system.
>
>The System works as follows:
>
>We have a Client Browser, a Web-Server, and a Certificatation
>Authority/Registration Authority.
>
>First of all, to use the Service I provide, the user must authenticate by
>either a username/password, Browser Cert or Smartcard.
>
>When the client goes to a certain page, they are requested to download a
>signed-persistent applet. The applet on first load will generate an RSA
>KeyPair, and a Certificate request. The Private key is stored, and the
>Cert Request is posted to a servlet on the web-browser. The servlet will
>check the request, and send it to an RA, which will automatically send this
>on to the CA, who will sign the cert, return it to the RA, who will in turn
>return it to the servlet.(Is this structure in place anywhere, I think
>Unicert does this automatic process.)
>
>Point: The cert doesn't tie to the user, as it was an automatic process,
>using an ARM, or worse, nothing, the only thing I have is that the user
>authenticated using their authentication mechanism, and that I can see the
>generated cert at a time that they were authenticated.
>
>On receipt of the CA signed cert, the servlet will save the cert(encrypted)
>to a database, and return it to the applet (anybody know how long it takes
>for the cert registration process to complete?) The applet will then save
>this to a disk(password protected in a PFX file in the JVM
>System.getProperty(" user.home") directory)
>
>When a signature for non-repudiation takes place, the applet is called to
>sign a piece of data, prompt the user for their password, and return a
piece
>of PKCS#7 data containing the signed data object, which is sent to the
>servlet, timestamped and stored in the users account for arbitration in the
>case of a dispute. Before the signature is stored, it is validated
against
>a CRL on the CA, and with the signing cert stored in the database, to make
>sure it is still the cert first applied for, otherwise it is rejected.
>
>That is the system. I can see one obvious point of attack:
>
>Someone inside my company could apply for a new certificate using the same
>automatic process, encrypt it, and store it, give the cert components
>including the private exponent to the user. The user will authorize a
>transaction which is supposed to be non-repudiable, and this validates ok,
>and the signed data get's stored.
>The insider replaces the origional encrypted cert. A dispute takes place
>and we see, hey the signature certificate doesn't match that in the PKCS#7
>object. Non-Repudiation fails.
>
>Notes:
>The user must authenticate with the authentication mechanism, thus, unless
>this is also replaced, and a bogus user created, we can show that the user
>had a part in this, or that their authentication mechanism was stolen by a
>malicious party.
>
>When a signature doesn't match in the arbitration process, we can tell
>straight off that the system was tampered with.
>
>Points:
>1. Without smartcards being used exclusively, the is no way to say for sure
>that the person is who they say they are.
>2. We can make this system as secure as we can from an insider attack by
>requiring smartcards to use database encryption/decryption functions which
>are done through a Hardware Security Module.
>3. The way that we are using the certs, a trail is left in the case of
>tampering, showing us that the user was wither negligent, or fraudulent,
>posing the question, would we be expected to take liability in the case of
>negligence or fraudulence?
>
>That is basically all I can say about the system. Please review this and
>give me feedback. It is a solution, but I'm not sure if it is the best
>solution.
>
>Best Regards,
>
>Kevin
>
>
------------------------------
** 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
******************************
