Cryptography-Digest Digest #165, Volume #9 Mon, 1 Mar 99 04:13:04 EST
Contents:
help with fractal image compression ("Krysta L. Halye")
A first attempt... ("Mike Murray")
Re: My Book "The Unknowable" (Neil Nelson)
Re: A New Public-Key Cryptosystem ([EMAIL PROTECTED])
ScramDisk Website?? ("T & C Spargo")
compression?security (alex)
XOR (alex)
Re: ScramDisk Website?? ("Chris Wilson")
Re: Quantum Computation and Cryptography (Jaap-Henk Hoepman)
Scramdisk Security ("Chris Wilson")
The strength of RSA (ring) vs DH/DSA (field) (Was: DSS Keys) ("Thomas J. Boschloo")
----------------------------------------------------------------------------
From: "Krysta L. Halye" <[EMAIL PROTECTED]>
Subject: help with fractal image compression
Date: Sun, 28 Feb 1999 20:25:01 -0500
i am a student researching fractal image compression. if anyone has
information about how it works, i would appreciate a helping hand.
thanks.
krys
------------------------------
From: "Mike Murray" <[EMAIL PROTECTED]>
Subject: A first attempt...
Date: Sun, 28 Feb 1999 21:09:19 -0500
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Hash: SHA1
Hey, people...
Though I might be relatively new reader to the crypto group, and
relatively new to cryptography in general, I'm interested in some
input from all of you. I've written a small C crypto program, based
loosely upon Ron Rivest's idea of "winnowing and chaffing", and I
think it might be relatively secure (although, to be honest, I've
written it with only a limited key size, and a small number of
possible hash values). To be honest, I don't know how to find out.
So, I'm including it at the bottom of this post. I'm hoping that
some of the people around here can help me find out.
So, hopefully I've done a good job...
Mike
P.S. Here's a message encoded with it; can it be broken?
3 1633689 4294832476 4448358 33957 6908733 365148 4294595440 7951932
294372 9546255 230040 12872682 529695 4479300 14467005 11088 18108360
443520 18423288 360180 337824 6298560 4294959277 21001761 4294624126
25981560 4291450624 403650 25587900 327888 8817984 4294273330 23324355
1753980 537030 36216720 967113 38480265 4294952392 37200870 426666
389610 38145654 4294913242 44877240 4294041646 40094271 4294042096
2089800 44601678 21912 45723609 4294662046 15116544 4294599016
4294905178 47731275 4294573696 58340412 4294800343 53675541 4294932898
158400 17635968 174762 65642805 2274168 68496840 4294933072 1620444
71390241 1482516 70543872 398475 68201595 0 255552 66922200 4294949374
22044960 4294680880 84321972 4294207744 1410084 80838081 1527936
85266756 69264 76763700 812076 41400 90541800
- ---------------------
/* CWEncrypt
*
* Mike Murray
* [EMAIL PROTECTED]
*
*
********************************************************
********************************************************
* Modifications/Dates *
*
*
* Initial Write:
*
* 02 / 22 / 99.
*
*
*
* Minor Modifications/Debugs *
* 02/28/99
*
*
*
********************************************************
********************************************************/
/* Brief Program Description:
***********************
* Using an algorithm similar to Ron Rivest's
* "Winnowing and Chaffing" algorithm, a program
* which SHOULD create unbreakable "encryption"
* of a set of data.
*
* Useage: CWEncrypt [security level] "Encrypt Key"
*
*
* Return Values:
*
* 0 -- Normal Program Termination
* 1 -- Improper Key Selection (i.e. key too long)
* 2 -- Improper Security Level
* 3 -- File Error
*
***********************/
/* Included header files */
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>
#include <math.h>
/* Defined Constants */
#define NUMLETTERS 53 /* letters and whitespaces */
#define MAXKEYLENGTH 10
#define MAXFILELENGTH 50
/* this would have been "defined", but it is long */
unsigned long int maxmacres = 215 * 1000;;
int hashTable [53] = { 3,1,4,1,5,9,2,6,5,3,5,8,9,7,9,
3,2,3,8,4,6,2,6,4,3,3,8,3,2,7,9,5,2,8,8,4,1,9,7,1,6,9,
3,9,9,3,7,5,1,5,8,2,9};
/* Function prototypes */
unsigned long int getMACRes (char *encodeKey);
unsigned short int getSeqNum (int mTwo);
int letterNo (char character);
unsigned long int encodeLetter (char character, int mOne, int mTwo,
unsigned int seq);
unsigned long int chaffLetter (unsigned long int res, int mTwo, int
mOne,
unsigned int seq);
int main (int argc, char *argv[])
{
unsigned long int result;
unsigned long int encode;
unsigned short int seqNum, security;
unsigned int macOne, macTwo;
unsigned int sequence, seqprev;
FILE *outfile, *infile;
char outfilename [MAXFILELENGTH];
char infilename [MAXFILELENGTH];
char cToE;
char keyString [MAXKEYLENGTH];
/* Level of security of encryption: the lower the number
* the more chaff packets are inserted. Default is
* 1 (i.e. highest level of security */
int secLevel = 1;
/* Process Command Line Args */
if (argc == 3)
{
secLevel = atoi(argv[1]);
if (secLevel == 0)
{
printf ("Security Level needs to be an integer");
return (2);
}
if (strlen(argv[2]) >= MAXKEYLENGTH)
{
printf ("Maximum Key Length is %d\n", MAXKEYLENGTH);
return (1);
}
else
strcpy (keyString, argv[2]);
}
/* If only one argument, security level is
* default value of 1 */
else if (argc == 2)
{
if (strlen(argv[1]) >= MAXKEYLENGTH)
{
printf ("Maximum Key Length is %d\n", MAXKEYLENGTH);
return (1);
}
else
strcpy (keyString, argv[1]);
}
else
{
printf ("Useage: CWEncrypt [security level] Encrypt Key");
return (3);
}
/* Get file for UnEncoded input */
printf ("Please enter a filename for input\n");
scanf ("%s", infilename);
printf ("Please enter a filename for output\n");
scanf ("%s", outfilename);
outfile = fopen (outfilename, "wb");
infile = fopen (infilename, "r");
result = getMACRes (keyString);
if (result == -1)
{
printf ("Only letters and spaces are allowed\n");
return (3);
}
macOne =(int) (result / NUMLETTERS);
macTwo =(int) (result % NUMLETTERS);
if (macTwo == 0)
macTwo = NUMLETTERS;
seqNum = getSeqNum (macTwo);
sequence = seqNum;
security = secLevel;
cToE = fgetc (infile);
fwrite (&seqNum, sizeof(unsigned short int), 1, outfile);
fputc (' ', outfile);
while ( feof(infile) == 0)
{
/* If the sequence has rotated back through the top
* of the integer range, set sequece to macTwo */
if (sequence < seqprev)
sequence = macTwo;
/* If this number is to be printed */
if ( (sequence % macTwo) == 0)
{
encode = encodeLetter (cToE, macOne, macTwo, sequence);
if ( (fwrite (&encode, sizeof(unsigned long int), 1, outfile)) !=
1)
return (3);
fputc (' ', outfile);
cToE = fgetc (infile);
}
else
{
/* If a chaff letter is to be printed */
if (security == 0)
{
encode = chaffLetter (result, macTwo, macOne, seqNum);
if ( (fwrite (&encode, sizeof(unsigned long int), 1, outfile)) !=
1)
return (3);
fputc (' ', outfile);
security = secLevel;
}
else
{
security--;
}
}
seqprev = sequence;
sequence += seqNum;
}
fclose (outfile);
fclose (infile);
return (0);
}
unsigned long int getMACRes (char *encodeKey)
{
int index;
int num;
unsigned long int result;
result = 1;
for (index = 0; encodeKey[index] != '\0'; index++)
{
num = letterNo (encodeKey[index]);
if ( num == -1)
return num;
result *= num;
}
while ( result >= maxmacres)
{
result = result/10;
}
return result;
}
unsigned short int getSeqNum (int mTwo)
{
int i;
short int seqNum;
seqNum = -1;
for (i = (int) sqrt(mTwo);i > 0; i--)
{
if ( (mTwo % i) == 0)
{
seqNum = i;
break;
}
}
if (seqNum == -1)
{
seqNum = 1;
}
return seqNum;
}
int letterNo (char character)
{
int result;
if (!(isalpha(character) || isspace(character)))
return (-1);
if ( isupper(character) )
result = hashTable[(int) character - 63];
else if ( islower (character) )
result = hashTable[(int) character - 96 + 27];
else if ( isspace (character) )
result = hashTable[0];
else
return -1;
return result;
}
unsigned long int encodeLetter (char character, int mOne, int mTwo,
unsigned int seq)
{
long result;
result = mOne * mTwo * seq * (int) character;
return result;
}
unsigned long int chaffLetter (unsigned long int res, int mTwo, int
mOne,
unsigned int seq)
{
unsigned long int result;
unsigned long int seed, cseed;
char character;
seed = (rand () + res) % rand ();
while ( (seed / res) >= 10 || (seed / res) <= 0.1)
{
if ((seed / res) >= 10)
seed = (seed / 10) + 1;
if ( (seed / res) <= 0.1)
seed = (seed * 10) + 1;
}
cseed = seed;
while ( cseed >= 256 || cseed <= 33)
{
if (cseed >= 127)
cseed = (long int) cseed / 10;
if (cseed <= 34)
cseed = cseed * 5;
}
while ( (seed % mTwo) == 0 && (seed % mOne) == 0
&& (seed % NUMLETTERS) == 0)
seed += 1;
character = (char) cseed;
result = seq * (seed / NUMLETTERS) * (seed % NUMLETTERS)
* (int) character;
return result;
}
=====BEGIN PGP SIGNATURE=====
Version: PGP 5.5.5
iQA/AwUBNtn2zv5WqcMdbVvFEQJYeQCgjaZmiR4IUiMDFRyBgIX/ITWeDXgAoIY5
ZBT02YpDIltgEyOjY9Iqsjz4
=HRzz
=====END PGP SIGNATURE=====
------------------------------
From: Neil Nelson <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.physics,sci.logic
Subject: Re: My Book "The Unknowable"
Date: Mon, 01 Mar 1999 03:08:22 GMT
In article <[EMAIL PROTECTED]>,
G. J. Chaitin wrote (http://www.umcs.maine.edu/~chaitin/unknowable/):
< In a nutshell, G�del discovered incompleteness, Turing discovered
< uncomputability, and I discovered randomness--
Bob Knauer wrote:
[ Chaitin's algorithmic prefix complexity randomness is not the true
[ randomness of quantum mechanics, and it so weak that it cannot even
[ be used for a crypto-grade OTP system.
[ Prefix complexity randomness is a very profound concept but it gets
[ its thrust by distinguishing description regularity from description
[ irregularity, and thereby discards regularity from consideration.
[ Such exclusions in a cryptosystem would cause a weakness in that
[ system since now the attacker knows that a certain class of
[ sequences are excluded.
[ One extraordinary thing about prefix complexity randomness is that
[ it is a property of the number itself and not the generation process
[ per se. This is in stark contrast to the notion of true randomness,
[ which is not a characteristic of the number per se but of the
[ generation process.
[ For example the sequence 101010...10 is not prefix complexity
[ random, although it is a true random number by virtue of its
[ generation by a TRNG.
[ However, prefix complexity randomness can be used to generate
[ indeterminant sequences, as Chaitin's Omega attests. Because of the
[ unsolvability of the halting problem, which can be mapped into a
[ system of integer equations that cannot be determined to provide a
[ finite or an infinite number of solutions, the bits of Omega are
[ random in the sense that that are completely indeterminant and
[ equidistributed (because Omega is Borel normal). But then Chaitin's
[ Omega is also infinite, which doesn't help much in building a
[ practical cryptosystem.
[ Only quantum mechanical processes are truly random in a practical
[ sense.
On _true_ randomness, mathematically, randomness is only with respect
to some non-random viewpoint; it says something _appears_ random as
against saying something _is_ random. _True_ or pure randomness does
not have an identifying procedure because there would be no non-random
vantage point from which to make sense of anything at all including
any randomness. _True_ randomness is an incoherent, self contra-
dictory notion by definition. Those two words can be combined but no
definite sense can be made of them.
The randomness of quantum mechanics cannot escape the incoherent
notion of true randomness but rather must say that phenomena appear
random with respect to necessary limits of scientific observation and
description methods. I.e., the randomness of quantum mechanics
_appears_ random, not that it _is_ random. Perhaps _is_ random could
be said in the context that no other better observation method can be
expected such that no assertion could possibly made against the
current _apparent_ randomness.
Cryptosystem randomness depends primarily on the description
complexity (expected smallest intertranslated description length in
the available computational languages generally and cryptolanguages in
particular) such that the search space, which increases exponentially
with a linear increase in description length, is sufficiently large to
likely avoid detection within the useful period if the encoded
message. And noting that as the ratio of the total complexity length
of the unencrypted messages to the description length of a particular
cryptosystem falls to 1, detection avoidance becomes increasingly
greater until it becomes certain at 1. (Also noting that processing
time is a factor, but that since there is a premium on processing time
in cryptosystems, this is a minor factor.)
In saying:
[ For example the sequence 101010...10 is not prefix complexity
[ random, although it is a true random number by virtue of its
[ generation by a TRNG.
it needs to be asked in what manner this sequence is used with respect
to cryptography. It would clearly not be wise to use such a string of
sufficient length as a bit overlay since the prefix complexity is
small and that sequence could be easily attacked. Apparently
non-random sequences appear randomly in relatively complex (relatively
random) sequences, but obviously not to a degree that a smaller prefix
complexity (cryptosystem description) can be easily found, or the
above detection ratio and ability increases. In the case in which the
previous sequence merely represents a cryptosystem complexity number
(in binary) in the increasing complexity order of cryptosystems, it
would be defined external to the prefix complexity applied to the
object cryptosystems and any apparent repetition in its representation
would have no bearing.
Neil Nelson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: A New Public-Key Cryptosystem
Date: Mon, 01 Mar 1999 04:01:12 GMT
[EMAIL PROTECTED] (Lowball61) wrote:
> [...]
In the example you gave, M can be split into two parts because of the
'expand' function. The even rows of M are in M1 and the odd rows are in
M2. Thus:
y = M1*x + M2*(0xFF + x)
where 'x' is the 00110100 (or any) plaintext. The "0xFF + x" is also due to
the expand function. Anyways, this can be re-arranged into:
y = M1*x + M2*0xFF + M2*x
= (M1 + M2)*x + M2*0xFF
ie, an affine transformation.
A more "general" expand() function would just replace 'x' and '0xFF + x'
with f(x) and g(x):
y = M1*f(x) + M2*g(x)
Which is as non-linear as f() and g() are, and basically put the status
of M into the "who cares" department: the system is only as secure as 'f'
and 'g' is, so why bother with M at all?
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "T & C Spargo" <[EMAIL PROTECTED]>
Subject: ScramDisk Website??
Date: 1 Mar 1999 05:41:50 GMT
Do I have the incorrect address, or, is the site down??
Please let me know, as this product is one of the best!!!
------------------------------
From: alex <[EMAIL PROTECTED]>
Subject: compression?security
Date: Mon, 01 Mar 1999 13:28:34 +0800
Reply-To: [EMAIL PROTECTED]
Hi,
Can any experts tell me that what is the relationship between dat
compression and data security? I am new in security and so where can I
pick up some basic materia?
Thanks
------------------------------
From: alex <[EMAIL PROTECTED]>
Subject: XOR
Date: Mon, 01 Mar 1999 13:30:06 +0800
Reply-To: [EMAIL PROTECTED]
Hi,
Why we need to use XOR to do the encryption process? Any other
operations that are better than XOR?
Thanks
------------------------------
From: "Chris Wilson" <[EMAIL PROTECTED]>
Subject: Re: ScramDisk Website??
Date: Sun, 28 Feb 1999 23:31:04 -0800
It seems strange that the site should go down in the UK, but I had the same
problem: it simply vanished. I have found an alternative:
http://www.ecn.org/crypto/soft/index.htm
T & C Spargo wrote in message <01be63a5$b6886ba0$df7ffcd0@default>...
>Do I have the incorrect address, or, is the site down??
>
>Please let me know, as this product is one of the best!!!
>
------------------------------
From: Jaap-Henk Hoepman <[EMAIL PROTECTED]>
Subject: Re: Quantum Computation and Cryptography
Date: 01 Mar 1999 09:28:06 +0100
[EMAIL PROTECTED] (Coen Visser) writes:
>
> fungus <[EMAIL PROTECTED]> writes:
> >
> >"R. Knauer" wrote:
> >>
> >> A quantum computer results in an exponential increase in computing
>
> No, as far as I know a n^2 increase in computing capability.
No, it's definitely an exponential increase in computing capability (although
it is hard to get the `gain' out). A quantum computer operating on n qubits can
(if the qubits are properly initialised) perform a function on all
2^n possible base states |00...00> .. |11...11> of these qubits `in parallel'.
Regards,
Jaap-Henk
--
Jaap-Henk Hoepman | Sure! We've eaten off the silver
Dept. of Computer Science | (when even food was against us)
University of Twente | - Nick Cave
Email: [EMAIL PROTECTED] === WWW: www.cs.utwente.nl/~hoepman
PGP ID: 0xFEA287FF Fingerprint: 7D4C 8486 A744 E8DF DA15 93D2 33DD 0F09
------------------------------
From: "Chris Wilson" <[EMAIL PROTECTED]>
Subject: Scramdisk Security
Date: Sun, 28 Feb 1999 23:44:22 -0800
I understand that Scramdisk sourse code is open for viewing and analysis.
Has anyone done so? Is there a critical analysis of Scramdisk?
What is generally thought of this program? I am thinking of using it, but I
have heard it referred to as a "medium" security solution to file
encryption. What are its weaknesses?
Thank you,
--- Chris
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: The strength of RSA (ring) vs DH/DSA (field) (Was: DSS Keys)
Date: Mon, 01 Mar 1999 09:39:11 +0100
[EMAIL PROTECTED] wrote:
>
> Who is Lutz Donnerhacke?
>
> I totally disagree with the substance of his post (and so does Bruce Schneier,
> RSA Labs, Roger Schafly et al).
>
> Read the references in my PGP DH vs RSA FAQ (when it's back online!). I am
> yet to find a single ref that supports this view.
>
[snip]
> > Here is his post:
[snip]
> > > A theoretical result is, that discrete logarithms over a finite field are
> > > at most as difficult as the factorisation of the predecessor of the
> > > characteristic of the field which is always prime.
> > > OTOH discrete logarithms over a finite ring are at most as difficult as the
> > > factorisation of the ring characteristic itself which is composite is this
> > > case.
> > > Several algorithms are knows to solve the problems. But it's unknown what
> > > algorithms are known to the secret services. The public knownlegde is
> > > documented in the standard P1363 of the IEEE. Appedix A says:
> > >
> > > Ring Field
> > > -----+---- -----+----
> > > 512 | 63 |
> > > 786 | 76 |
> > > 1024 | 86 1024 | 56
> > > 2048 | 117 2048 | 112
> > > 3072 | 139 3072 | 128
> > > 4096 | 157 4096 | 168
>
> Where is this table from? 1024-bit DSA is thought to have an approx. strength
> of a 2^80 symmetric cipher! Nowhere near 56 bits!
_From IEEE P1363 Appendix A, I hope! I haven't gone throught the trouble
to subscribing to their mailing list at
http://grouper.ieee.org/groups/1363/draft.html. But Lutz seemed to know
what he was talking about. At least he knew of the existance of the
document?
Forgive me for crossposting, but I just wanted to be sure ;)
Thomas
--
Seven of Nine: "You will be assimilated"
PGP key: http://x13.dejanews.com/getdoc.xp?AN=406702465
Post your keys to news:alt.security.keydist
------------------------------
** 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
******************************
