Cryptography-Digest Digest #867, Volume #10 Sat, 8 Jan 00 06:13:00 EST
Contents:
Re: Wagner et Al. ("Joseph Ashwood")
Re: Problem with using a multiple byte XOR as a hash? (Scott Fluhrer)
Re: Questions about message digest functions (Scott Fluhrer)
Re: AES wise? (Tim Tyler)
Re: Wagner et Al. (Tom St Denis)
Re: Problem with using a multiple byte XOR as a hash? (Johnny Bravo)
Domain name and properties for sale. ([EMAIL PROTECTED])
Re: OLD RLE TO NEW BIJECTIVE RLE (Tom St Denis)
I want to know if this works? (Jeff Lockwood)
Implementation of RSA ("Alex English")
Re: Implementation of RSA (David A Molnar)
An interesting science web site (Chad Schofield)
Re: Followup: Help Needed For Science Research Project (Pelle Evensen)
Re: PKZIP compression security ([EMAIL PROTECTED])
Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?) (Guy Macon)
Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?) (Guy Macon)
Re: Unsafe Advice in Cryptonomicon (Guy Macon)
Re: Wagner et Al. (Guy Macon)
----------------------------------------------------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Date: Fri, 7 Jan 2000 19:02:12 -0800
Since you're still not recognising that what you claim is in fact not
completely correct, let's go into another example, while it is not simple,
it is still possible. The proof of concepts for this are JAVA and VmWorks.
Simply write a just in time compiler for x86 on x86 filtering for the calls
you're looking for, the difference in speed is not likely to be noticed (a
fraction of a percent) and your access to the program is complete.
Joe
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: Problem with using a multiple byte XOR as a hash?
Date: Sat, 08 Jan 2000 03:24:14 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (ChenNelson) wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I'm thinking of writing a routine that would store a key in some sort
>of key file, encrypted of course. To open the key, the user must enter
>a previously selected passphrase. My question is, how would I detect
>the entry of the wrong passphrase, which would produce garbage as the
>key, and alert the user? Is it safe to store the key's bytes taken as,
>say pairs, all XOR'ed together in sequence and store that as part of
>the file "header" in the clear?
The problem is: if the attacker has access to the hashed (XOR'ed) version,
he can easily reconstruct a passphrase to generate that. With SHA (or
any other good hashing function), this is computationally infeasible.
--
poncho
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Date: Sat, 08 Jan 2000 03:31:52 GMT
In article <[EMAIL PROTECTED]>,
"Matt Timmermans" <[EMAIL PROTECTED]> wrote:
>I missed the start of this thread, but as far as I know, there are no known
>one-way permutations that can be shown to be permutations -- do you
>actually know of one, Tim?
Doing modular exponentions can be shown to be a permutation without giving
away any secret material. That is, you can find particular values of g and p
such that:
f(x) = (g**x) mod p
can be demonstrated to be a permutation from (1..p-1) to (1..p-1), without
there being any known way to compute the inverse in a reasonable period of
time.
--
poncho
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: AES wise?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 8 Jan 2000 02:57:00 GMT
Terry Ritter <[EMAIL PROTECTED]> wrote:
: sci.crypt Tim Tyler <[EMAIL PROTECTED]> wrote:
:>Having siad this, I see /very/ little *harm* in restricting the operations
:>used to bent functions. It's not as though testing them is terribly
:>time-consuming.
: Bent functions are not balanced; they have unequal probabilities for
: 1's and 0's.
"Those balanced boolean functions whose minumum distance from the
affine functions is at a maximum", is probably something like what I
should have said, then.
However, I was under the impression that the contents of s-boxes in
Feistel networks can in principle be *any* boolean function at all - with
the Feistel structure taking care of the reversibility.
Under these circumstances, the use of balanced functions does not appear
to be compulsory - though I can understand that it might be desirable to
avoid functions whose outputs don't balance their inputs for other
reasons.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
I have seen the truth ... and it makes no sense.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Date: Sat, 08 Jan 2000 03:53:28 GMT
In article <855djf$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Guy Macon) wrote:
> Here is where we part company. The argument that imperfections in
> a scheme make the scheme not worth doing is a fallacy. It's like
> saying that a car thief can break into my car with a slimjim and
> hotwire it, so I might as well leave the doors open, the key in the
> ignition, and the engine running. Even easy to defeat security
> measures are often worth doing.
No but would you make your doors out of titanium [sp?] etc... Remotely
PB is very secure [ I believe ] since I used ciphers I trust in methods
I trust. This is to say if you have a message I sent you will most
likely not read it. This protects 99% of all PB users. Since well the
chances of you hacking into my computer is very slim.
I think what you guys are arguing is OS safety and not PB related
safety. Even PGP is attackable with trojans... But only if the trojans
get there.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Problem with using a multiple byte XOR as a hash?
Date: Fri, 07 Jan 2000 22:53:17 GMT
On 08 Jan 2000 01:30:09 GMT, [EMAIL PROTECTED] (ChenNelson) wrote:
>I'm thinking of writing a routine that would store a key in some sort
>of key file, encrypted of course. To open the key, the user must enter
>a previously selected passphrase. My question is, how would I detect
>the entry of the wrong passphrase, which would produce garbage as the
>key, and alert the user? Is it safe to store the key's bytes taken as,
>say pairs, all XOR'ed together in sequence and store that as part of
>the file "header" in the clear?
You could terminate the key with a known value like 10 '/0'
characters before encrypting it. The odds of an incorrect entry
decrypting with 10 '/0' characters at the end are exceedingly low.
Then have the program remove the 10 '/0' characters before using the
keyfile.
Best Wishes,
Johnny Bravo
------------------------------
From: [EMAIL PROTECTED]
Subject: Domain name and properties for sale.
Date: Sat, 08 Jan 2000 03:55:09 GMT
Apologies for commercial tone of this message, but
we thought it would be of interest to this newsgroup.
**************************************************
One our of our asset management clients develops identity management
technology ("muses") utilizing encryption, agents, proxies, and filters.
We are disposing of their assets at this time. We are auctioning off the
domain names anonymuse.com and anonymuse.net, along with other
intellectual properties and rights. Minimum bid for the domain names is
$2000. For information on software technology and other properties,
please send SASE and e-mail address to the address below.
If you have an interest, please reply to:
DCP CORP.
BOX 6753
Evansville, IN 47719
Thank you.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: OLD RLE TO NEW BIJECTIVE RLE
Date: Sat, 08 Jan 2000 04:01:14 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> John Savard <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
> : (For myself, while I too think removing certain reduncancies from
> : compression have their uses, I quarrel with any attempt to emphasize
> : one-to-one purity at the expense of bias. [...]
>
> Bias in the resulting compressed file is certainly important.
>
> Which is /more/ important depends partly on the relative sizes of the
bias
> caused by lack of elimination of redundancies in the plaintext, and
the
> bias introduced by a lack of 1-1 compression.
Actually the point of encryption is to eliminate bias. Compression is
suppose to simply remove redundancy. So your point is moot.
While 1-1 huffman was semi-interesting, RLE coding is not even worth
looking at. he should make a one-to-one deflate algorithm.... that's
where the money is at. Oh yeah and it has to compress with a >=
efficiency as the current deflate.... :)
Let me re-iterrate
COMPRESSION = MAKE SMALLER
ENCRYPTION = MAKE RANDOM
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jeff Lockwood <[EMAIL PROTECTED]>
Subject: I want to know if this works?
Date: Sat, 8 Jan 2000 17:26:47 +1100
/*******************************************
rat data stream scrambler:
try it out.
Written to compile with gcc under linux
this source code is released free of any
restrictions. you may use and distribute
it; or any parts of it, any way you like.
J Lockwood
January 8 2000
*******************************************/
#include <stdio.h>
#include <unistd.h>
#include <termios.h>
#include <fcntl.h>
#define uint unsigned long int
#define uchar unsigned char
struct termios tto,ttn;
uchar junk[256],key[256];
void setmode()
{
if (isatty(STDIN_FILENO))
{
tcgetattr(STDIN_FILENO,&tto);
tcgetattr(STDIN_FILENO,&ttn);
ttn.c_lflag &= ~(ICANON|ECHO);
ttn.c_cc[VMIN]=1;
ttn.c_cc[VTIME]=0;
tcsetattr(STDIN_FILENO,TCSAFLUSH,&ttn);
}
}
void restoremode()
{
if (isatty(STDIN_FILENO))
tcsetattr(STDIN_FILENO,TCSAFLUSH,&tto);
}
void fill()
{
uint a,b=256,c;
int file=open("/dev/random",O_RDONLY);
for(a=0;a<256;a++) junk[a]=a;
setmode();
fprintf(stderr,"creating Keyfile, you may have to press some keys\n");
fprintf(stderr,"until the count equals 0\n");
for(c=0;c<256;c++)
{
do
{
read(file,&a,1);
a=a%b;
} while(a==c);
key[c]=junk[a];
junk[a]=junk[--b];
fprintf(stderr," %d \r",b);
}
close(file);
fprintf(stderr,"Keyfile Complete\n");
restoremode();
fwrite(key,256,1,stdout);
}
loadkey(char *x)
{
FILE *file;
file = fopen(x,"r");
if(!file) exit(50);
fread (key,256,1,file);
fclose(file);
}
void encode(char *x)
{
uchar a=0,b=128;
uchar a1;
loadkey(x);
for(;;)
{
a1=key[b]^fgetc(stdin);
if(feof(stdin)) break;
b=key[a]^a1;
fputc(b,stdout);
a=a1;
}
}
void decode(char *x)
{
uchar a=0,b=128;
uchar b1;
loadkey(x);
for(;;)
{
b1 =fgetc(stdin);
if(feof(stdin)) break;
a=key[a]^b1;
fputc((a^key[b]),stdout);
b=b1;
}
}
main(int argc,char **argv)
{
if(argc>1)
{
if (argv[1][0]=='k') { fill(); exit(0); }
if (argv[1][0]=='e')
{
encode(argv[2]);
exit(0);
}
if (argv[1][0]=='d')
{
decode(argv[2]);
exit(0);
}
}
printf("\n\tUsage:\n\n");
printf("\rat k >keyfile to create a key\n");
printf("\rat e keyfile <infile >outfile to encode \n");
printf("\trat d keyfile <infile >outfile to decode \n");
}
Jeff Lockwood <[EMAIL PROTECTED]>
PGP public key:
homepages.ihug.com.au/~satan/pgpkey.asc
------------------------------
From: "Alex English" <[EMAIL PROTECTED]>
Subject: Implementation of RSA
Date: Fri, 7 Jan 2000 22:41:17 -0800
Im having some difficulties implementing RSA. I code in MSVC++ 6 and I need
to find a way to represent and do arithmetic on extremely large (200 digit)
numbers. Obiously a long int is not enough to do this, as it's only 8 bytes
long. Has anyone else run into this problem? If so, can anyone suggest
something?
-alex
PS does anyone know where I can get an implementation of blowfish that
compiles cleanly under MSVC6 ?
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Implementation of RSA
Date: 8 Jan 2000 06:59:58 GMT
Alex English <[EMAIL PROTECTED]> wrote:
> long. Has anyone else run into this problem? If so, can anyone suggest
> something?
Do a search for "big integer" or "multiprecision integer
library." Investigate alternatives. One such is NTL
(http://www.shoup.net/); it provides a class called "ZZ" which
acts a lot like an int, except it handles really big numbers.
Then download some chapters from the Handbook of Applied Cryptography
on Euclid's extended algorithm, and computing with modular arithmetic.
You'll be up and running with a bit of coding work.
Thanks,
-David
"What is coding theory? It's the dual of ding theory!"
-seen on sci.math
------------------------------
From: Chad Schofield <[EMAIL PROTECTED]>
Subject: An interesting science web site
Date: Sat, 08 Jan 2000 08:34:49 GMT
Hello,
During my time on the internet, I have come across a lot of interesting
web sites that deal with science. I thought some of you would find them
usefull so I decided to share them with you...
http://www.pe.net/~cschofi1/science/
Thank you for your time,
Chad Schofield
------------------------------
From: Pelle Evensen <[EMAIL PROTECTED]>
Subject: Re: Followup: Help Needed For Science Research Project
Date: Sat, 08 Jan 2000 10:09:41 +0100
segals-2 ([EMAIL PROTECTED]) wrote:
: I've seriously considered several of the responses that I have received. I
: was looking into different factoring methods, as an investigation into the
: weaknesses and strengths of RSA. I have also looked into tracing the
: improvements in cryptography as well as attacks on cryptosystems, and
: possibly making a prediction about the future of these fields. However,
: I think I've decided on the following idea (which was posted in response to
: my query to this newsgroup): Encrypt text using RC4 (and possibly other
: symmetric algorithms as well) and then find the probability of finding a
: particular character in the encrypted message. Basicly, count the total
: number of characters and the total of number of each character. I believe
: that the probability in this particular case would be 1/255 (i think that's
: the one). If a higher probability occurred for some characters, or lower
: for others, it could be concluded that RC4 did not completely turn the text
: message into "random garbage". I could experiment with various types of tex
: t (random, novel, dictionary--which would have a larger number of repeated
: letters than a novel, most likely) and with various keys, just to broaden
: the base of the experiment and to solidify my results. I am hoping to
: determine whether or not RC4 is as dependable as is believed.
Bob Jenkins has done some analysis of RC4 and there is a slight bias;
http://www.burtleburtle.net/bob/rand/isaac.html#RC4code
For a good test suite for (pseudo) random number generators see;
http://www.helsbreth.org/random/diehard.html
A mathematical description of the tests are here;
http://stat.fsu.edu/pub/diehard/cdrom/pscript/
I'd suggest that you try something else than RC4. The reason being that
there are no (known) strong biases. The likelihood of coming up with any
surprising results is not very big. A more fun and rewarding thing to
do would perhaps be to show why most common system psuedo-random generators
are not sufficient for use as stream ciphers. Even analyzing a few common
good non-cryptographic PRNGs (KISS or a MWC generator for example) could
probably be very interesting as well as making for a good demonstration of
"cryptography is harder than it looks". Considering that a great many
"ordinary programmers" consider the default system PRNG to "work well"
for cryptographic applications, this would be something very useful to
point out. :-)
It's not difficult to build something that behaves reasonably well when it
comes to statistical tests. To build something that produces statistically
reasonable output, is cryptographically secure (i.e. it should be infeasible
to derive the key or determine the state from the output) and is fast is
quite a lot trickier, or so I've been told. ;-)
Good luck with your project.
/Pell
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PKZIP compression security
Date: Sat, 08 Jan 2000 09:58:43 GMT
On Wed, 05 Jan 2000 13:39:01 GMT, [EMAIL PROTECTED]
wrote:
>In terms of security, zipping first (or other form of compression)
>removes some redundancy from the data. This makes it marginally less
>easy to attack, although with most forms of strong encryption
>available these days, the improvement is probably esoteric.
That would seem to be the obvious answer, but remember that zipping
also imposes a very strict format on the data - if you are unlucky
enough to have all your compression tables at the beginning of your
file, then there's a lot of information to work with...
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?)
Date: 08 Jan 2000 05:41:35 EST
William Rowden wrote:
>
>I'm joining the topic drift.
>
>Dan Day wrote:
>
>> I still recall the day when I first discovered that the written
>> "chaos" and the spoken "kay'os" were the same word...
>
>I, too, was a reading child. "Omnipotent" is logically "omni-potent"
>/om'nee poe'tent/, right? I also remember the quizzical look I
>received when I first said "annihilation," complete with two short
>i's. Why is that "h" there?
Oddly enough, I can answer that question. What is happening is that
the way we pronounce words shifts while the spelling remains.
"Colonel" used to be prounounced as it is spelled.
There is speculation that the wide distribution of movies and TV
shows from the past has stopped this drift, and that we are moving
towards everybody speaking with a southern california accent
(because that's where the TV shows are often made).
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?)
Date: 08 Jan 2000 05:46:57 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tony T.
Warnock) wrote:
>"unionize" is fun to give to automatic hyphenation routines.
Here are two sentences to give to automatic language translators:
Time flies like an arrow.
Fruit flies like an orange.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Unsafe Advice in Cryptonomicon
Date: 08 Jan 2000 05:56:56 EST
Steve K wrote:
>come to think of it, it would all be buzz.
>haven't played with motors in ages...
Ah but *WOULD* it be a detectable buzz? We are all familiar with
a 60 Hertz electromagnet with a spectrum that is a single sharp
spike plus a few odd harmonics, but I suspect that an electromagnet
that is driven by a good pseudorandom signal followed by a well
chosen high pass filter would be able to erase floppies, hard
drives, etc. without a noticable buzz. I can't figure out how
to calculate whether my suspicions are correct. If anyone really
wants the answer, just hire me and I will do the experiment. :)
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Wagner et Al.
Date: 08 Jan 2000 06:08:29 EST
In article <856cbk$rk1$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom St Denis) wrote:
>
>In article <855djf$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Guy Macon) wrote:
>> Here is where we part company. The argument that imperfections in
>> a scheme make the scheme not worth doing is a fallacy. It's like
>> saying that a car thief can break into my car with a slimjim and
>> hotwire it, so I might as well leave the doors open, the key in the
>> ignition, and the engine running. Even easy to defeat security
>> measures are often worth doing.
>
>No but would you make your doors out of titanium [sp?] etc...
Nope. That's why I said "often worth doing". Everything in life
is a series of tradeoffs, and in this case you have to factor in
the amount of harm to you if your message is read, what kind of
attacker is likely (Script Kiddy? NSA? Local Police Dept?). and
how much time and money you have available. "Best possible" is
usually even stupider than "None".
>I think what you guys are arguing is OS safety and not PB related
>safety. Even PGP is attackable with trojans... But only if the trojans
>get there.
Agreed, and (in the case of PGP) only if the trojan is customized
to attack PGP, and has NT administrator rights. The latter is very
unlikely if your system administrator understands security.
------------------------------
** 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
******************************
