Cryptography-Digest Digest #26, Volume #9 Wed, 3 Feb 99 08:13:02 EST
Contents:
Re: Who will win in AES contest ?? (DJohn37050)
Re: Encryption using shell script - Anything out there? (John Bailey)
Re: Java random (fungus)
Cipher Saber help page ("Jay")
Re: *** Where Does The Randomness Come From ?!? *** (Marty Fouts)
Re: Foiling 56-bit export limitations: example with 70-bit DES (fungus)
What cipher is used by iomega in ZIP products ? (Geoffrey Milos)
Re: What cipher is used by iomega in ZIP products ? (Paul Rubin)
Re: Encryption using shell script - Anything out there? ("tiglath")
Re: Random numbers generator and Pentium III ("Trevor Jackson, III")
Re: RNG Product Feature Poll (Terry Ritter)
Re: Cracking 128bit (Paul Crowley)
Re: Crypt Info ???? (Gurripato (x=nospam))
Re: [question/challenge/HELP ME! IEE!] Another unheard of punk who thinks hes come
up with something new... (Cuykens Anthony)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Who will win in AES contest ??
Date: 3 Feb 1999 00:12:26 GMT
I agree and is the subject of my submission.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: Encryption using shell script - Anything out there?
Date: 3 Feb 1999 00:11:27 GMT
On Tue, 2 Feb 1999 16:01:10 -0500, "Joseph Suriol" <[EMAIL PROTECTED]>
wrote:
>I wonder if there is any symmetrical encryption algorithm implemented using
>a shell script.
>I doesn't have to be tremendously secure, just more serviceable than a
>rotation or XOR. \
Does http://www.ggw.org/donorware/flip.html
qualify?
I think its the only game in town. I would be interested in doing an
alphanumeric version in Perl as an encore.
John
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Java random
Date: Tue, 02 Feb 1999 19:32:30 +0100
Else wrote:
>
> Please comment on this scheme of generating random number in Java:
>
> seed instance of Random as
>
> Random rnd = new Random( System.currentTimeMillis() ^ (new
> Object().hashCode() << 16) );
>
> then
>
> for( int i=0;i<n;i++ )
> rnd = rnd.nextInt( );
>
> where n is a number of times one thread runs while another one sleeps for
> 100 ms. It's in the range of 90,000 - 150,000 on my machine.
>
> then I get the random sequence of 16 bytes which I use to generate RC4 key.
>
The java random number generator is 48 bits internally. No matter how
good your seed is, you're only selecting one of 2^48 possible keys.
2^48 is only six bytes. This means that ten of your 16 bytes of key are
worthless, they can be predicted from the first six bytes.
:)
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: "Jay" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Cipher Saber help page
Date: Tue, 2 Feb 1999 19:53:30 -0500
I suspect that many beginners may want to try implementing CipherSaber
(http://ciphersaber.gurus.com ) but find the description a bit ambiguous.
I have written more detailed information, but still no code...you've got to
write that part yourself!! Also read the Cipher saber page first, then look
at mine when you are ready to get to work.
http://www.freespeech.org/freethought/CipherSaber.htm
Jay
--
=====BEGIN PGP PUBLIC KEY BLOCK=====
Version: 2.6.2
mQCNAzCmKpkAAAEEANq8z8b2fiVI8rB3n3iJVyqDSGu7KdYy0hE95DDAbkh017ew
oTEASfiZmP7mPXy9y7HWi9oYYIY1eGSH9Xe/oGLOfjoETKGES6YqObRJ5B5LmK+y
Xxsv89NCw/K7s/OSm+CscewZqXt0cHnHFx7/9heGEqDNii3xgdXsLniA5KoFAAUR
tB9KYXkgSG9sb3ZhY3MgPGhvbG92YWNzQGlvcy5jb20+
=c5gz
=====END PGP PUBLIC KEY BLOCK=====
------------------------------
Crossposted-To: sci.skeptic,sci.philosophy.meta
Subject: Re: *** Where Does The Randomness Come From ?!? ***
From: Marty Fouts <[EMAIL PROTECTED]>
Date: 02 Feb 1999 17:13:44 -0800
>>>>> R Knauer pounded silicon into:
> On Tue, 02 Feb 1999 21:12:02 GMT,
> [EMAIL PROTECTED] (John Savard) wrote:
>> Quantum mechanical randomness is true - and implies the Universe
>> is an "open system", but only to a limited extent not
>> corresponding to the usual meaning of the term "open system",
>> since nothing but randomness can be accessed quantum
>> mechanically, there is really no way of truly knowing that this
>> randomness is coming from somewhere else.
> Why should randomness have to come from somewhere? Why not state
> that randomness is a lack of order, and ask where order comes from
> instead?
because, perhaps, 'order' is a poorly understood concept?
--
that is all
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Wed, 03 Feb 1999 03:56:50 +0100
>
> I assumed:
> (i) DES is automatically exportable from the US and, (ii) DES is a 56-bit
> cipher. Both are true.
>
ie. The NSA is so good at cracking DES that they don't care about it
any more.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: Geoffrey Milos <[EMAIL PROTECTED]>
Crossposted-To: alt.iomega.zip.jaz,alt.iomega.zip.jazz
Subject: What cipher is used by iomega in ZIP products ?
Date: Tue, 02 Feb 1999 23:02:57 -0500
Can anyone shed some light on which cipher Iomega uses to encrypt data
when a ZIP drive is password protected ? It troubles me that this
info is not revealed on their www site (at least, I couldn't find it
there).
------------------------------
Crossposted-To: alt.iomega.zip.jaz,alt.iomega.zip.jazz
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: What cipher is used by iomega in ZIP products ?
Date: Wed, 3 Feb 1999 04:12:45 GMT
In article <[EMAIL PROTECTED]>,
Geoffrey Milos <[EMAIL PROTECTED]> wrote:
>Can anyone shed some light on which cipher Iomega uses to encrypt data
>when a ZIP drive is password protected ? It troubles me that this
>info is not revealed on their www site (at least, I couldn't find it
>there).
The data is not encrypted. The passwords are quite easy to defeat.
------------------------------
From: "tiglath" <[EMAIL PROTECTED]>
Subject: Re: Encryption using shell script - Anything out there?
Date: Wed, 3 Feb 1999 02:01:51 -0500
Thank you for your reply, this is pretty good but I was thinking about a
Korn Shell or awk script to use in UNIX.
Thanks.
John Bailey wrote in message <[EMAIL PROTECTED]>...
>On Tue, 2 Feb 1999 16:01:10 -0500, "Joseph Suriol" <[EMAIL PROTECTED]>
>wrote:
>
>>I wonder if there is any symmetrical encryption algorithm implemented
using
>>a shell script.
>>I doesn't have to be tremendously secure, just more serviceable than a
>>rotation or XOR. \
>Does http://www.ggw.org/donorware/flip.html
>qualify?
>I think its the only game in town. I would be interested in doing an
>alphanumeric version in Perl as an encore.
>
>John
------------------------------
Date: Tue, 02 Feb 1999 21:41:13 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random numbers generator and Pentium III
R. Knauer wrote:
> On Tue, 02 Feb 1999 11:42:23 -0600, Jim Felling
> <[EMAIL PROTECTED]> wrote:
>
> >I, having not read the references being referred to (as of yet) concede the point
> >for now but I do reserve the right to at a later time after having read the work in
> >question to quibble with your conclusions. ( it just sounds wrong -- this may be due
> >to my intuition misleading me though - so I accept yield the point to you
>
> Quibble away - I am not an expert at this stuff. I am just giving my
> best shot at my understanding, which is always subject to refinement.
>
> I will mention that either this book by Li and Vitanyi is extremely
> interesting, just like Chaitins papers on the Web, or I am missing the
> whole point and it could just be more dry, dull, boring mathematics.
> The authors put just enough spin on their exposition to make me think
> this is exciting stuff, but it could all be just a bunch of hype that
> I am not qualified to see thru.
>
> >I feel that, while it may not be as reliable as the above tests, it is still
> >something worth doing. Every tool I use to test such a system can only add to my
> >confidence in the system. There is no excuse for not testing such a system in every
> >way possible so as to avoid an unanticipated weakness from 'breaking' your system.
>
> Would you still make that statement if the test were shown to be
> meaningless, or even counterproductive? If I told you that only TRNGs
> made in cubic boxes will give good results and appealed to your sense
> of symmetry to justify it, would you use that as a criterion for
> proving up a TRNG?
>
> >I feel that such analysis is necessary, but not sufficient to 'certify' such an
> >instrument. I want to test the output and not merely rely on the 'fact' that this
> >was a professionally designed machine made to rigorous standards, etc. and unless
> >things have changed the only tools I have for such testing are statistical.
>
> What if the tests are meaningless, and can give false results?
>
> >I disagree -- how about changing that statement to: That confidence is based upon
> >rigorous design, thorough review of the design, skilled calibration of the system,
> >not merely statistical tests.
>
> Testing the output does not fall into any of those categories. Testing
> the output is not "skilled calibration of the system". There is no
> calibration possible with meaningless tests.
>
> >I feel that any testing that can be done should be done.
>
> Even if it is meaningless, and can give false results that are
> detrimental?
>
> >And if a generator fails
> >such a test it should be immediately pulled from service thoroughly examined,
> >calibrated, etc. and then retested and if it passes then allowed back into service.
>
> The only tests I would use on the output are ones that can be traced
> back to known hardware malfunctions, like a shorted or grounded
> output. All other strings are acceptable outputs for a TRNG.
>
> >Ok, then how do you test your device as it runs? How would you determine whether
> >your device is a working TRNG, and not a poor substitute( whether due to design
> >flaw, sabotage, miscalibration, or accident)?
>
> By running diagnostics on the subsystems, not the output.
>
> Lets say someone did sabotage your TRNG in such a way that it put out
> strings that passes our tests on the output. Now what are you gonna
> do?
>
> >I agree one should not reject any strings (either use or do not use the device) --
> >but one should still evaluate the device.
>
> The only evaluations are those that have a known reason for a
> malfunction. Since a TRNG is not necessarily malfunctioning when it
> fails a statistical test, that cannot be used to diagnose it reliably.
>
> >Wrong. I agree that rejecting strings based upon criteria is bad, but there are
> >methods that can be used to correct possible bias. that are of use.
>
> Lack of bias is not a valid criterion deciding the randombess of
> finite strings.
>
> If you understand the specification for a TRNG, and why it results in
> proveable security, you will see why it is meaningless to use
> statistical tests on the output - no matter what the results of those
> tests are, they are meaningless.
>
> Statistical tests which purport to give results based on "good" and
> "bad" strings is meaningless. The only two strings that are "bad" are
> all 1s (open output) and all 0s (shorted output).
How long does the run have to be before you decide it isn't random? Be careful how you
reply. It will be tempting to use a probabalistic argument which will imply you are
using a statistical test to validate the outputs.
BTW, I think alternating ones and zeros are just as bad as alls ones or all zeros. Any
other readers want to vote on alternating bits one way or the other?
Any readers want to pick a number of bits N all the same that indicate a flaw rather
than
a random output?
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: RNG Product Feature Poll
Date: Wed, 03 Feb 1999 09:08:23 GMT
On 3 Feb 1999 08:01:03 -0000, in
<[EMAIL PROTECTED]>, in sci.crypt Paul Crowley
<[EMAIL PROTECTED]> wrote:
>[...]
>The Right Way to do randomness, as I understand it, is to get your
>device to produce output as raw as possible and use that output to
>drive a CPRNG.
Leaving aside, for the moment, the idea that what we really need is a
hash and not a RNG, isn't it a bit silly to use a supposedly-strong
and thus "cryptographic" transformation on true random data?
If the data are random, nothing that we can do can possibly protect
them better.
If the data are not random, we might as well use a polynomial counter
and a cipher.
What we really have is biased random data. But one of the roles of a
hash is to distribute information and throw some away so that whatever
regularity appears on the input can no longer be located from the
result. Even linear hashes do this. We don't need no steenkin'
crypto hash here.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Cracking 128bit
Date: 3 Feb 1999 07:32:10 -0000
[EMAIL PROTECTED] (Albert P. Belle Isle) writes:
> >http://www.securitydynamics.com/products/datasheets/securpc.html
> >
> >"...Cracking a single 128-bit RC4 key is an effort costing an
> >estimated half billion dollars and taking more than six months to
> >achieve."
> This is a reputable company offering real numbers for someone wanting
> to include the outside possibility of such brute-force attacks in his
> cost-benefit analysis for buying INFOSEC products versus the value of
> the data to be protected. Obviously, such attacks are the least of
> most people's worries.
Except that the numbers are made up out of thin air.
> Anyone whose adversaries are dumb-enough to limit themselves to
> trying to crack his (strong) cipher, rather than searching for
> statistical weaknesses in his keystream generator [...] has little
> to fear.
I think I'm the only person ever to have demonstrated a lasting
statistical weakness in the RC4 CPRNG output (though Andrew Roos has
successfully attacked the first few bytes) and I don't think a bias of
one part in 2^24 will do an attacker very much good...
--
__
\/ o\ [EMAIL PROTECTED] http://www.hedonism.demon.co.uk/paul/ \ /
/\__/ Paul Crowley Upgrade your legacy NT machines to Linux /~\
------------------------------
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: Crypt Info ????
Date: Wed, 03 Feb 1999 08:07:31 GMT
On Tue, 02 Feb 1999 16:36:34 GMT, [EMAIL PROTECTED] (Albert P.
Belle Isle) wrote:
>The widely-rumored cooperation of the Swiss-based reincarnation of
>Boris Hagelin's firm (Crypto AG) with NSA (through Germany's BND) has
>not helped their commecial prospects very much, and wouldn't recommend
>itself as a business strategy to any business manager alert to the
>hazard of shareholder lawsuits.
>
I have several times heard about CryptoAG, but know no details
about it and all the fuss around it. Can somebody provide some
pointers? Thanx
------------------------------
From: Cuykens Anthony <[EMAIL PROTECTED]>
Subject: Re: [question/challenge/HELP ME! IEE!] Another unheard of punk who thinks hes
come up with something new...
Date: Wed, 03 Feb 1999 13:21:58 +0100
Vektor,
I think that it was a good idea not to post the code because it would be
not relevant in a first time. What I think could be of some use is the method
explained in more details. Could you make a description of all the operations
that are performed to convert plain text into cipher text?
Thank,
Vektor wrote:
> I'm new to the encryption scene, getting into it merely for a program I
> am currently writing, which would require some form of encryption to
> prevent snooping. I've read some FAQs, and a whole mess of web pages
> dealing with encryption, and i've had more words than i can count
> without taking my socks off tossed at me (Sbox? *insert Tim Allen grunt
> of choice here*). So obviously, you can see me in the perfectly painted
> picture of a naive youth from some 120 person town in the big city,
> gawking at all the big pretty buildings.
>
> It has been presented to me that the flaming death of many an encryption
> system has been the fact that a random number is so very hard to obtain,
> and that many psuedo-random number generators just flat out couldnt cut
> a fart with a butterknife.
>
> Well. I thought about this. I thought long, and i thought hard, thought
> naked, and probably while i was sleeping (though I cant remeber any of
> the dreams), and it occured to me...'Why not turn this to an advantage,
> instead of a fault?'.
>
> *pause while the assembled onlookers recovers from thier fits of
> laughter.*
>
> I'm going out on a limb here...I know the basis of many of the common
> encryption schemes, RSA derivitives, etc. I've been told by people 'Dont
> do your own. Base it on someone elses.' But still I battle on, knowing
> that in the end, i'll probably be laughed to an early grave, but here
> goes.
>
> (BTW, I haven't read anywhere about this being done, or any 'popular'
> schemes that use it, and as it seems to me to be fairly sound, since its
> not 'popular' i'm assuming that mine is an original idea)
>
> Since the output of a pseudo-random number generator can be discovered,
> simply by recreating its inputs, why not use this fact AS part of the
> encryption?
>
> Say I have an algorithm, that simple takes a text-based key, a password,
> for instance, and generates x numbers, basically by MODing, XORing, and
> several other methods, of differing size and whatnot, sorting them, then
> comparing them to thier original locations, and deriving from that, a
> string of x numbers, essential 'random', but easily recreatable if you
> have the method AND the password. (from what i understand, most PRNG are
> based in this way, by trying to snag things that would be considered
> 'random', like background noise, or mousemovements, etc.).
>
> Well...now i have as many numbers as i want, that i can do with as i
> please, AND I can recreate this string of 'random' numbers, based on a
> simple (or not so simple) key.
>
> (...3 weeks after this idea...3 long weeks...sometimes lit only from the
> harsh glow of my CRT...many packs of cigarettes and cups of coffee)
>
> I know have a small program that implements a scheme, based on this
> ability to re-generate a string of random numbers. A string of random
> characters, An offset, and a new Mrandomize and MRND function, a little
> bit of creative XORing, MODing, and some interesting uses of fairly
> large arrays, I think (I THINK darnit...i need some help verifing this
> :)) I have a pretty damn good scheme.
>
> basically...the output is pseudo-random garbage. the input is 2 keys,
> they can be textbased, or not. repetetive series of characters, such as
> 'aaaaaaaaa' 'abababababab' !@#!@#!@#!@#!@#' all encrypt into random
> noise, with no indication of what is where, no pattern at all.
>
> The program is written in VB5.0 ... i know, i know...ick gack vb and all
> that, BUT...source code is available if you E-MAIL me...i dont want to
> post it here, because its just huge.
>
> I guess it could be classified as stream encryption (its not really
> block). But heres some examples :
> --------------------------------------------------------------------
> "This is a test of the My Encryption Method."
> Generates :
> "��*��fyt�î�5!e���� ��Z�0|yg��Z;Ϭ�"
>
> "1111111111111111111111111111111111111111111111111111111111111111111111111"
> Generates :
> "�jmaa� ������p�"�s��
> ���vxg��+�� a�ͷ� Hu����ӌ� ��C_�gjv|��"
>
> "BOY I'M GONNA FEEL REAL SILLY IF THIS HAS BEEN DONE BEFORE"
> Generates :
> ����%M��G}�_d)�������!�z��'&����9y
> !BJ� ��Md���#���
> --------------------------------------------------------------------
>
> I know you probably get this alot, but please dont flame me (even though
> I've read through almost all the posts I downloaded today, and didnt see
> one non-helpful post), but I'd like your input on the whys and whynots
> of this type of encryption scheme.
>
> heres what i see as strong/weak points :
>
> Strong : Even with repeating characters, a string of almost totally
> random characters is created.
>
> Strong : 2 keys, one for generating the pseudo-random numbers, and one
> for encryption, 9 bytes min length. 18^256 (which overflows my calc)
> utter maximum possible combinations (I think...its been a while since i
> was in any kind of math class) 256^256, if you try to calculate the
> random matrix itself (just brute forcing it, anyways)
>
> Weak : 2 keys, 9 bytes min length...noone wants to have to remember 2
> stinkin keys.
>
> Weak : USES keys...anyone listening in on key transmission (phone,
> internet, whatever) would be able to de-crypt the message (IF they knew
> the method)...even though some sort of public key encryption on them
> would probably take care of this
>
> Strong : The heart of it is psuedo-random numbers, and so the output is
> basically random. I would think this would prevent developing some sort
> of algorithm to decrypt, and would also prevent any kind of 'theres this
> character here, and here, and here...i think its a K' analyzing.
>
> ANY comments, questions, flames, 'bonehead, what do you think
> Blah-De-Blah encryption uses', etc. will be welcomed.
> If you want the source to the VB class i used to encrypt/decrypt, I will
> be more than happy to give it to you (is there an export law that
> prohibits source code?). If I could get some inputs, like 'you could use
> such and such an algorithm' or 'i worked on it for 5 minutes, and
> cracked your scheme', Or just some general tips and pointers from some
> highly-respectable crypto-gods...i'd be just overwhelmed with happiness.
>
> Please keep in mind though, that if you use big encryption related words
> on me, i'm probably going to scratch my head and say 'duh'.
>
> Email - vektor_@hotmail(bleh).com
> ICQ - 16841690
>
> or you can find me on #visualbasic in efnet, as Vektor_
>
> (BTW...if you cant tell, i'm VERY long winded...I'm sorry if this is a
> long, terribly boring post, but when I start, its just so hard to stop.)
>
> -----------------------------------------------------------------------
>
> ���L`�i�v�����9��]ט4���>�������5f��
>
> ^^^^^^ nice little message, encrypted, using my little scheme...both
> keys were only 2 bytes long, so i'm not exporting anything illegal (i
> hope)
--
Anthony Cuykens
Architecture & Cryptography,
Research & Development,
PROTON WORLD International
------------------------------
** 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
******************************
