Cryptography-Digest Digest #109, Volume #13 Mon, 6 Nov 00 13:13:01 EST
Contents:
Re: Crypto Export Restrictions (James Felling)
Re: hardware RNG's (Alan Rouse)
Re: Detectable pattern in encoded stegaanographic images (Andre van Straaten)
Re: XOR Software Utility (freeware) available from Ciphile Software (Andre van
Straaten)
Re: CHAP security hole question ([EMAIL PROTECTED])
Re: Microsoft's script encoder (Andre van Straaten)
Re: Psuedo-random number generator (Mok-Kong Shen)
Re: On obtaining randomness (Dan Oetting)
Re: Client Puzzle Protocol (Darren New)
rijndael and public/private key encryption (shren)
----------------------------------------------------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Mon, 06 Nov 2000 10:01:06 -0600
Anthony Stephen Szopa wrote:
> Scott Craver wrote:
> >
> > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> > >Scott Craver wrote:
> > >>
> > >> It's kind of someone else to work to translate your
> > >> descriptions into real pseudocode, but the onus really
> > >> is upon you to do this.
> > >
> > >The onus is on you: That is if you have the intelligence and energy
> > >and interest.
> >
> > Uh, no, the onus is upon _you_, because it is _your_ product.
> > Nor is the onus upon consumers to perform their own automobile
> > crash tests.
> >
> > Without letting experts scrutinize your algorithm, you can not
> > back up the single claim that your product is not a piece of
> > worthless snake-oil. Your angry attitude, towards those who
> > would help you scrutnize the algorithm, only reinforces the
> > perception of Original Absolute Whatever as insecure.
> >
> > >If not: forget about it.
> >
> > Sorry, no can do. As long as you have that web site up
> > peddling what appears to be snake oil, people have the
> > responsibility to follow-up to your posts, and otherwise warn
> > consumers that they should be using ciphers and PRNGs that have
> > been thoroughly tested.
> >
> > Not to mention the performance issue of a piece of software
> > requiring the user to do part of its calculations, using
> > counters or playing cards. Nutty!
> >
> > -S
>
> Like I said, if you do not have the intelligence and the energy and
> the interest to read the Help Files and have all your questions
> answered then just forget about it.
Yep. If someone wants to do any real analisys of your program they have to
make a substantial investment of time and energy in order to even begin to
apply proper analisys -- sounds like you encourage people to evaluate your
cypher's quality.
>
>
> Don't you think you have wasted enough of your time already?
>
> Since you have demonstrated that you will not even devote the time
> and energy to read the Help Files you clearly don't know what you
> are talking about regarding OAP-L3.
>
> I think that even you have the intelligence to understand the
> software. Like the old saying goes: "You can lead a horse to water
> but cannot make him drink."
As someone who has invested the effort I have the following things to say
about your software.
1) It has perhaps the slowest key setup methodology of any product available
today.
2) It utilizes its key material in a manner that is HIGHLY inneficient.( the
user types a heck of alot more info in than he should otherwise have to,
3) If the user is naieve about permutations and/or lazy you algo is insecure
and does not warn the user of this condition.
4) Your algorithim is either space or memory inefficient in comparison to
other stream cyphers.
I wll say security can be achieved with this method( or so my admittely
amateur analisys of the algo over the course of a couple of weeks seemed to
indicate), but that achiveing such is far more effort than it is worth.
>
>
> OAP-L3 encryption software requires true random user input. Proven
> methods of generating truly random data is demonstrated in several
> common gambling games. Believe me, these are proven random games.
> People bet their life's savings on them. Trillions of dollars every
> year are wagered on them.
Well, firstly gambling games DON'T generate true random numbers -- they
generate "good enough" random numbers -- there are people who exploit this on
a regular basis. ( Roulette to use a specific example has been shown to have
enough of a bias that can be exploited to allow substantial winnings to be
accumulated, and card players do use certian 'artifacts' of shuffling to
attack such games.)
>
>
>
> Yet you know better than all these people around the world.
>
>
> You forgot numbered beans shaken in a bottle and drawn out one by
> one.
Umm... that is also prone to certian kinds of bias.
>
>
> Yep. Obtaining pure golden random numbers sure is "nutty."
No I don't think it is.
>
>
> Anyone who uses encryption software that does not generate pure
> random numbers is nutty if you ask me.
(ummm... your software doesn't do this. I hate to breaki it to you, but your
software is INCAPABLE of doing this.)
>
>
> OAP-L3 requires true random number user input then generates pure
> random numbers for encryption purposes.
Perhaps a better way of stating this is "OAP-l3 requires a random key, and
then generates the stream associated with that key for encryption purposes.
Decryption requires the same key." This is true of any other stream cypher
as well.
>
>
> But you say this is nutty.
What you claim -- that your algo produces 'pure random numbers' is either
fraudulent, distorted, meaningless, or trivial -- it depends upon what
exactly you mean by 'pure random numbers' -- in any case it falls into 1 of
those classes.
If you are claiming an algortihmic source of true random numbers -- you are
simply lying such CANNOT exist.
If you are claiming that your algorithim outputs numbers that contain the
entropy of the keys input -- then you are making either a trivial statement
or you are distorting the facts in that your algorithim does not make optimal
use of such key entrophy.
Or you have defined 'pure random numbers' in such a way so as to have it mean
something that is completely different than the way it is used in the real
world.
<snip insult>
------------------------------
From: Alan Rouse <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Mon, 06 Nov 2000 16:19:10 GMT
In article <[EMAIL PROTECTED]>,
David Schwartz <[EMAIL PROTECTED]> wrote:
>So long as you get some randomness in, you will get some randomness
> out. So long as you get enough randomness in, you will get enough
> randomness out. Anything else that goes in has no effect. The form
that
> randomness is in has no effect.
The problem is knowing how much randomness you have.
For cryptographic purposes, you are trying to achieve a certain
expected effort to find the key via brute force. That implies a
certain number of possible values, with equal probabilities for each
value. There are two general problems that can keep you from achieving
that goal.
First, you might have a smaller set of possible values than you
expect. That can result because your source of supposedly random
inputs doesn't have as many possibilities as you expect. Or it can
result because your hash (or PRNG) function doesn't map all your
possible inputs uniquely to an equal number of outputs. (In other
words, two different inputs might yield the same output).
The second way it can fail is if the possible input values happen with
different probabilities. If this is the case, an attacker who
understands the problem can search the most likely values first,
reducing the expected time to find the target value. You might be
able to overcome by increasing the size of the input seed. But the
difficulty is in knowing how much is enough. As far as I know, the
best you can do is to estimate carefully and then add a lot more bits
than you think you need, and hope it is enough.
I don't know of a good way to overcome the faulty PRNG / hash problem.
Perhaps the best you can do is to use a PRNG based on a well-studied
crypto function such as DES, whose weaknesses are well understood, and
take into account the resulting weaknesses in your random outputs.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Andre van Straaten <[EMAIL PROTECTED]>
Subject: Re: Detectable pattern in encoded stegaanographic images
Date: Mon, 06 Nov 2000 16:32:50 GMT
[EMAIL PROTECTED] wrote:
> In article <8tsqgv$uv1$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>>
>> upon closer examination and comparison of e-mails with the plain
>> parchment bmp background, and the same background with a textfile
>> steganographically hidden within the background, found a very clear
>> pattern in the base 64 encoding {when viewing the 'message source' and
>> the encoding of the .bmp }, but no obvious patterns in the encoding of
>> the plain .bmp
>>
> follow -up,
> have tested .gif, .jpg, .wav formats,
> no obvious detectable pattern found in the base-64 encoding,
> have changed the parchment bmp background to a .gif format, put the
> same pgp file in using s-tools 4 , no detectable pattern found in the
> base 64 encoding,
> with the .bmp format, if the base 64 encoding is viewed without line-
> wrapping {as block of lines of equal length - the default view when
> checking message source, in full screen view }
> there is an obvious clear pattern of columns of M and N as repeating
> 4th characters throughout the block,
> would recommend to stay away from .bmp format for steganography
> [at least, if done from s-tools 4 ]
> vedaal
I had a short look at some .bmp image files, and found they look
quite different.
These ones used generally as simple backgrounds, as your original
.bmp file, have bytes mostly with lower numbers.
Your original .bmp file shows:
Arithmetic mean value of data bytes is 18.0727 (127.5 = random).
The numbers in a byte increase with the complexity of the image.
Maybe I haven't searched long enough, but I didn't found an .bmp
with the high numbers in a byte like yours with the PGP file
embedded. I had arithmetic mean values of around 100, generally.
Your .bmp file with the embedded PGP file shows:
Arithmetic mean value of data bytes is 198.4216 (127.5 = random).
So, it's quite suspicious even without statistical analysis that
your .bmp file with the embedded PGP file has very high numbers
in a byte, but shows only a simple background image.
=====
If your interested in a program for statistical analysis of
randomness, there are many, complex and simple ones.
The one I used, is quite simple, called "ent" and free with
description at:
http://www.fourmilab.ch/random
As it is a C file for the command line, I have written a wrapper
in Tcl/Tk, which eases the call of files from different directories.
If Tcl/Tk is installed, you can use it on MS Windows, Unix, and
elsewhere. It's on my Web site. See footer below, go "Scripting" and
then "GUI with Tcl/Tk".
For identifying repetitive patterns, search for "Kasiski" on the Web
or Deja.com.
I have a C program which does not show only the Kasiski factors, but
also the repetitive patterns with its occurrences, so I can abuse it
for these purposes.
(I forgot the source and changed mine slightly.)
These are only raw tools. A professional cryptoanalyst has probably
more sophisticated ones.
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
______________________________________________
flames please to [EMAIL PROTECTED]
------------------------------
From: Andre van Straaten <[EMAIL PROTECTED]>
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Date: Mon, 06 Nov 2000 16:37:40 GMT
In sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>> XOR Software Utility (freeware) available from Ciphile Software
>>
>> This software simply performs the universally available logical XOR
>> process on two files chosen by the user and outputs the resulting
>> file.
>>
>> http://www.ciphile.com
>>
>> goto the Downloads Currently Available web page.
>> scroll to the bottom of the page.
>>
>> Click on the blue anchor tag: CiphileXOR_10.zip (155kb)
> How on earth did you make such a simple program take 155kb?
> Tom
The GUI makes the overhead.
The program itself is very short. The core is a while loop
with three statements.
A similar program with a repeated key instead is in the first
chapters of Bruce Schneier's "Applied Cryptography".
Just a few weeks ago, I wrote the same thing in C++ and Tcl/Tk.
Only my GUI (in Tcl/Tk) looks nicer. I have three entry fields
for the files, and only if you press "Browse" appear the same
file selection boxes he uses.
I didn't publish this stuff, as I thought that thousands before
me have done something similar.
But if someone really means he wants a copy of the source code,
C++ or Tcl/Tk, I'll send him one or post it.
I won't put everything I write in my spare time on my Web site.
This way you could check out how lame I am. ;-)
My interest was to find out how different implementations on
different platforms cope with the new line character(s).
The disadvantage of the OTP is that only one added or left
character in the key file or ciphertext file messes up the rest
of the plaintext file.
(E.g.: encrypting on Unix and decrypting on MS Windows)
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
______________________________________________
flames please to [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: CHAP security hole question
Date: Mon, 06 Nov 2000 16:36:44 GMT
In article <8u6eph$56d$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> > > That SRP, EKE, and so forth do not solve the
> > > authentication problems most
> > > of people is not merely ignorance and inertia.
> >
> > I think it is exactly ignorance and inertia.
>
> Well, I suspect patents and other intellectual property restrictions
> are a third reason that the EKE, SRP, etc. protocols aren't more
widely
> deployed.
I agree. This was the principle reason I created SNAKE
(other than to see if I could :-)
A brief decription of the SNAKE key exchange...
The SNAKE Key Exchange creates a key from multiple
(1 or more) DH Key Exchanges which are performed
concurrently using a prime modulous based on the
shared weak secret. SNAKE is unpatented and public
domain and may be used without restriction.
U User or client identifier
P hash of passphrase
X[0..n-1] set of n large random numbers (Client)
Y[0..n-1] set of n large random numbers (Server)
R a large random number (Client)
S a large random number (Server)
f(k,P,R) a function which constructs a large safe
prime number. k is a small integer 0..n-1
g the generator, a fixed public value, and a
primitive root for all f() values
K shared session key
H() crypto hash function (SHA1,TIGER,or similar)
E[K](Z) means 'encrypt Z with key K' using a block
cipher
^ means 'to the power of'
Message1: Client --> Server (client chooses R, X[0..n-1])
U, R, g^X[0] mod f(0,P,R), g^X[1] mod f(1,P,R), ...
Message2: Server --> Client (server chooses S, Y[0..n-1])
S, g^Y[0] mod f(0,P,R), g^Y[1] mod f(1,P,R), ...
Message3: Client --> Server
E[K](S)
where K=H(P,Message1,Message2,
(g^Y[0] mod f(0,P,R))^X[0] mod f(0,P,R),
(g^Y[1] mod f(1,P,R))^X[1] mod f(1,P,R),
...)
Message4: Server --> Client
E[K](R)
where K=H(P,Message1,Message2,
(g^X[0] mod f(0,P,R))^Y[0] mod f(0,P,R),
(g^X[1] mod f(1,P,R))^Y[1] mod f(1,P,R),
...)
NOTES:
n is the number of SNAKE 'parts', it is a small fixed
public integer > 0.
g must be in the range sqrt(max f())+1 .. min f()-1,
and a primitive root for all f().
X[k] values must be chosen such that g^X[k] mod f(k,P,R)
is not 0,1 or g, and is < min f(). The Server must
check that the values sent by the Client are valid.
Y[k] values must be chosen such that g^Y[k] mod f(k,P,R)
is not 0,1 or g, and is < min f(). The Client must
check that the values sent by the Server are valid.
When the Server receives Message3 it authenticates the
Client by decrypting and checking S using the shared
session key K. If the decrypted value for S does not
match the vaue sent in Message2, then authentication
fails and Message4 should not be sent.
When the Client receives Message4 it authenticates the
Server by decrypting and checking R using the shared
session key K. If the decrypted value for R does not
match the vaue sent in Message1, then authentication
fails.
After the key exchange is complete the session key can
be used to encrypt all data in both directions, or as
an initializer for some other encryption mechanism, such
as a stream cipher.
SNAKE can be applied to any two entities which wish to
do mutual authentication, they are not required to be
'clients' or 'servers'.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Andre van Straaten <[EMAIL PROTECTED]>
Subject: Re: Microsoft's script encoder
Date: Mon, 06 Nov 2000 17:06:22 GMT
Sundial Services <[EMAIL PROTECTED]> wrote:
> Which is a good reason not to get into such a "marriage!" :-)
> The only time you can put your trust into a scrambling system is when
> you thoroughly understand how it works. Your adversary can download a
> cracker from a warez site faster than you can blink. And =you= will be
> "the only fool who doesn't know he's naked" because of course your
> adversary will never clue you.
> The problem with most encoding schemes is that =they= must be able to
> decode the file, in order to execute it, with zero-knowledge of the key
> (in plain or encrypted form) from the user. This means that the key
> must be present, and concealed. Which means that a determined hacker
> can find it. Which means that a cracker-program can, and has, been
> written to find it automatically.
> Microsoft is famous for their "XOR-table" security and at first blush
> I'd just assume they've done the same thing again. But people look at
> the Microsoft logo and simply assume that "if it's from Microsoft, it's
> gotta be good." That's the power of a brand.
The XOR algorithm with short keywords is the only one I can decipher,
at the moment.
I hope this endangered species won't die out :-;
Since I don't buy their software anymore, I find these Microsoft guys
really pleasant. They are so helpful. LOL
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
______________________________________________
flames please to [EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Mon, 06 Nov 2000 18:15:46 +0100
David Schwartz schrieb:
>
> Herman Rubin wrote:
> >
> > In article <8ts3j8$8vo$[EMAIL PROTECTED]>,
> > Alan Rouse <[EMAIL PROTECTED]> wrote:
> > >In article <[EMAIL PROTECTED]>,
> > > David Schwartz <[EMAIL PROTECTED]> wrote:
> > >> Who said anything about being balanced or having exactly maximal
> > >> entropy? I'm talking about having sufficient entropy for cryptographic
> > >> purposes, nothing more, nothing less
> >
> > >How much entropy is sufficient? Enough to support the design criteria
> > >of the encryption. Presumably a cryptosystem designer would select the
> > >key size, such that the size of the brute force attack would be
> > >sufficiently large--that is, above some design threshold.
> >
> > The total amount of entropy in a pseudo-random generaor
> > is the amount in the key. Running a computer program
> > cannot generate entropy.
>
> Please take a look at http://youknow.youwant.to/~djls/entropy.c for a
> counter-example to this claim. While running a computer program cannot
> _generate_ entropy, it can certainly mine it. There's plenty of entropy
> in the world around us, much of it easy to get to.
Your program processes physical randomness, while he meant
that a stream from a PRNG (often realized in software)
can't contain more entropy than the key (seed), because all
that is derived deterministically.
M. K. Shen
------------------------------
From: Dan Oetting <[EMAIL PROTECTED]>
Subject: Re: On obtaining randomness
Date: Mon, 06 Nov 2000 10:18:22 -0700
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> If I choose ten books
> and put them in series, the
> number of possibilities is astronomical.
> So if I use a
> sufficiently long secret key to make such a choice
Does this secret key magicaly appear or will you be using some
predictable ritual to create it. If you could pull a random secret key
out of your head you wouldn't need the rest of this process.
> it is
> almost certain that the opponent can't know which set
> (sequence) of books I use,
Unless they get a court order requireing the local book store to turn
over the records of which books you purchased. (sorry, just had to throw
in a little local politics)
> Then I shuffle these in small units
Shuffling is another process that uses a random source to make
decissions yet you don't explain where this random source originates.
> Finally I use a good hashing
> algorithm to concentrate the entropy, leading to
> sufficiently good randomness and ensuring that the
> opponent can't reverse my processing.
This is good, if your opponents steals your random number you don't want
them to be able to deduce what books you read :)
You are starting from the undenyably huge entropy of all words that
could be written. But reduce this to the set of books printed by one
publisher. Your entropy is now at most the number of books published
since the content of these books is fixed and known. You choose and
shuffle which adds more entropy but only if this entropy is from a
secure random source. Your choice of books could be leaked since it
requires external access to the books. And you could use the very best
PRNG for the shuffle but it will add no entropy if it starts from a
known state. You might as well just draw 10 numbered beans from a can.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Client Puzzle Protocol
Date: Mon, 06 Nov 2000 17:30:10 GMT
[EMAIL PROTECTED] wrote:
>
> Hi,
> It's been quiet a while since RSA announced the client puzzle protocol,
> in the paper they claim the protocol can me layered over TCP/IP as a
> solution to TCP SYN Flooding, but is this really possible without
> modifying TCP itself?
Where's this discussed?
There's an interesting discussion at http://grc.com/r&d/NoMoreDoS2.htm that
looks to me like it would work for a large class of DoS attacks.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
The tragedy of the commons applies to monitizing eyeballs, too.
------------------------------
From: shren <[EMAIL PROTECTED]>
Subject: rijndael and public/private key encryption
Date: Mon, 06 Nov 2000 17:58:58 GMT
Can Rijndael be used for public/private key encryption? I'm new to the
whole cryptography field, but like every other programmer on the planet
I'm working under deadlines.
Looking at the code:
int makeKey(keyInstance *key, BYTE direction, int keyLen, char
*keyMaterial);
int cipherInit(cipherInstance *cipher, BYTE mode, char *IV);
int blockEncrypt(cipherInstance *cipher, keyInstance *key, BYTE *input,
int inputLen, BYTE *outBuffer);
int blockDecrypt(cipherInstance *cipher, keyInstance *key, BYTE *input,
int inputLen, BYTE *outBuffer);
int cipherUpdateRounds(cipherInstance *cipher, keyInstance *key,
BYTE *input,
int inputLen, BYTE *outBuffer, int Rounds);
It looks like it's only geared for single key encryption, using the
same key for encryption and decryption. Am I missing something?
------------------------------
** 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
******************************
