Cryptography-Digest Digest #731, Volume #10 Mon, 13 Dec 99 12:13:01 EST
Contents:
Re: Insecure PRNG? (Guy Macon)
Re: Simple newbie crypto algorithmn (Eric Hambuch)
Re: Simple newbie crypto algorithmn ("Tim Wood")
Re: Simple newbie crypto algorithmn (CLSV)
Re: Simple newbie crypto algorithmn ([EMAIL PROTECTED])
Re: Simple newbie crypto algorithmn (CLSV)
Re: Linear Congruential Generators ("Tony T. Warnock")
Re: Questions about message digest functions (James Felling)
Re: Linear Congruential Generators ("Tony T. Warnock")
Re: Better encryption? PGP or Blowfish? (SCOTT19U.ZIP_GUY)
Why no 3des for AES candidacy (UBCHI2)
lfsr based cryptosystem ([EMAIL PROTECTED])
Re: Why no 3des for AES candidacy (Anton Stiglic)
Re: The future of telecommunication? ("Tim Wood")
Re: Better encryption? PGP or Blowfish? (Neil Bell)
Re: some questions about DES (Anton Stiglic)
Re: Why no 3des for AES candidacy ("Tim Wood")
Re: Are thermal diodes as RNG's secure (Tim Tyler)
Re: some questions about DES (Paul Koning)
Re: Simple newbie crypto algorithmn (Glenn Larsson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Insecure PRNG?
Date: 13 Dec 1999 06:56:32 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Mok-Kong Shen)
wrote:
>
>CLSV wrote:
>> So what is stronger: a steel or a wooden beam?
>> Again, given no context there is no valid comparison.
>> *Proving* real-world characteristics is much harder than proving
>> theoretical concepts.
>
>Look into an engineering handbook and you will find the strength
>of different construction materials. Note however that a beam is a
>structure. Its breaking load depends on its cross-section etc. and
>is much more complicated than (but can be computed from) the 'pure'
>strength of the material it is made of. Given a steel and a wooden
>beam, an engineer can do computations to determine which is stronger
>and give a numerical figure for that. To do the same with two
>crypto algorithms seems to be very hard or impossible in general.
Actually, this is an excellent analogy. Steel has tensile strength
that is much better than stone but the compressive strength isn't
so superior. Wood has different strengths in different directions.
As an erngineer, I can not answer the question "what is stronger:
a steel or a wooden beam?". It depends on what kind of load and
on what kind of support the beam has. Just like crypto strength
depends on what kind of attack.
------------------------------
From: Eric Hambuch <[EMAIL PROTECTED]>
Subject: Re: Simple newbie crypto algorithmn
Date: Mon, 13 Dec 1999 13:16:25 +0100
Steven Siew wrote:
> 2. The program must be cryptographically powerful enough not to be cracked
> even by using all the computers in the world in less than a 1000 years.
[...]
> It will create a 607 bytes key file which should be almost completely
> random.
That means: Your key size is 4856 bits. Many algorithms are good if they
are used with such a long key. But normally you want to encrypt "long
secrets" (e.g. files)
with "short secrets" (keys etc.), so you should use the shortest key as
possible (of course long enough to prevent brute-force).
> The program uses permutation or "card shuffling" type tricks to encrypt the
> original text (plaintext). It also makes use of XOR to further confuse the
> attacker.
I will have a detailed look at your algorithm this evening.
So long
Eric
------------------------------
From: "Tim Wood" <[EMAIL PROTECTED]>
Subject: Re: Simple newbie crypto algorithmn
Date: Mon, 13 Dec 1999 12:21:41 -0000
<big Snip>
>
>It you need to generate a random key but you dont have a source of pure
>random bytes then you can use the following trick.
>
> gzip -9 bigfile
> scramble bigfile.gz < bigfile.gz > key9
> scramble key9 < key9 > key8
> scramble key8 < key8 > key7
> scramble key7 < key7 > key6
> scramble key6 < key6 > key5
> scramble key5 < key5 > key4
> scramble key4 < key4 > key3
> scramble key3 < key3 > key2
> scramble key2 < key2 > key1
> tail -c 607 key1 > key
> rm key1 key2 key3 key4 key5 key6 key7 key8 key9
> gunzip bigfile.gz
>
>It will create a 607 bytes key file which should be almost completely
>random.
>
It's a minor point, but shouldn't that read
It will create a 607 bytes key file which should appear random, and should
be harder to recreate than brute-forcing the key.
There is no randomness at all in this generation method (unless I'm much
mistaken) only secrets.
<very big snip, source code of algorithm>
tim
--
**<Stolen line alert>**
>From my one-bit brain with a parity error.
**</Stolen line alert>**
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: Simple newbie crypto algorithmn
Date: Mon, 13 Dec 1999 12:27:58 +0000
Steven Siew wrote:
> [...] It's not uncommon to hear things like "All codes that have been invented so
> far (with the exception of one time pads) have been broken by the NSA."
Where do you hear such things?
> [...] That of course is total bullshit. Anyone with basic C programming skills and
> basic high school maths can write a crypto algo that the whole world cannot
> crack in less than 1000 years.
Yes, I wonder why we bother to have this newsgroup anyway ;-)
> So I set about proving the above statement. In short I want to write a
> crypto program with the following chracteristics: [...]
And how does this prove that *anyone* with basic C programming skills
and basic high school maths can write an "unbreakable" crypto algorithm?
Mind you, I don't dispute your fairly optimistic claim as I haven't got
the time right now to look at your code, but do you have any prove of
the strength of your algorithm? Have you tried to break it yourself?
Regards,
Coen Visser
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Simple newbie crypto algorithmn
Date: Mon, 13 Dec 1999 12:41:56 GMT
<snip>
> It also makes use of XOR to further confuse the attacker.
Why ? Risking to sound like a textbook: isn't that just Security
By Obscurity ? By reversing this calculations, one could disregard the
xors, right ?
<bigger snip>
Regards,
Martin
Crypto-newbee...
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: Simple newbie crypto algorithmn
Date: Mon, 13 Dec 1999 14:35:21 +0000
Steven Siew wrote:
[...]
> So I set about proving the above statement. In short I want to write a
> crypto program with the following chracteristics:
Ok. Some quick observations.
> It you need to generate a random key but you dont have a source of pure
> random bytes then you can use the following trick.
>
> gzip -9 bigfile
> scramble bigfile.gz < bigfile.gz > key9
> scramble key9 < key9 > key8
> scramble key8 < key8 > key7
> scramble key7 < key7 > key6
> scramble key6 < key6 > key5
> scramble key5 < key5 > key4
> scramble key4 < key4 > key3
> scramble key3 < key3 > key2
> scramble key2 < key2 > key1
> tail -c 607 key1 > key
> rm key1 key2 key3 key4 key5 key6 key7 key8 key9
> gunzip bigfile.gz
1 How many times do you have to run your algorithm for security?
Shouldn't one time be enough? Or else define the number of cycles.
> The idea is simple. The fastest growing maths function in high school maths
> is factorial. A simple example is this. The number of ways a race of 7
> runners can finish is 7! or 7*6*5*4*3*2*1 ways. The number of ways a deck of
> 52 cards can be shuffled is 52! And it grows very very very fast. If we
> encrypt a 64kb file, we can do it by shuffling 65536 * 8 = 524288 bits. The
> number of permutation is of course 524288! which is a big number. To say
> 524288! is a big number is an understatement.
2 This is not correct.
The number of permutations of A B C D is 4! = 24,
the number of permutations of 1 0 1 1 is only 4.
You are assuming 524288 different bit values while there
are only two. A problem is that the number of permutations
depends on the specific plaintext. A plaintext with all zeros
has just one permutation. That could be the start of an attack.
Regards,
Coen Visser
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Date: Mon, 13 Dec 1999 08:38:24 -0700
Reply-To: [EMAIL PROTECTED]
If you use LCG's with power-of-two modulus, there are some strong
structural relations. The bottom bit (assuming full cycle) alternates
010101, then next bit has a cycle of length 4, then next is cycle 8,
etc. The first half of the entire cycle is the equal to the second half
with the top bit flipped. The first, second, third, and fourth, quarter
cycles are identical except for the first two bits, etc. For non-full
cycle generators, the same holds except that the cycle is only 1/4 as
long.
A long cycle (128 bit) LCG with only the leading bit exposed is
difficult to decode but it should be possible with a lattice reduction
computation.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Date: Mon, 13 Dec 1999 09:45:42 -0600
Tim Tyler wrote:
> wtshaw <[EMAIL PROTECTED]> wrote:
> : In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> :> wtshaw <[EMAIL PROTECTED]> wrote:
> :> : In article <[EMAIL PROTECTED]>, Pelle Evensen <[EMAIL PROTECTED]> wrote:
>
> :> :> Have there been any papers published on
> :> :> 1a) Whether SHA-1 is a permutation for a message the same length as the
> :> :> digest-length (160 bits)? [snip]
> :> :> 1c) Is this true (or can it be true) for any other, supposedly secure,
> :> :> one-way, collision resistant, hash-functions?
> :>
> :> : 1c holds a host of sins of presumption.
> :>
> :> Another wtshaw cryptic comment ;-)
>
> [snip]
>
> : Since you asked, I resolve a portion of my comment: collisions and
> : security of a hash function work in opposition, no collisions meaning
> : that the input can be solved, be that perhaps inconvenient. But, if
> : lots rode on the solution, it might be worth it.
>
> I'm almost as lost as when you started.
>
> Surely collision resistance and security are generally positively
> connected - rather than negatively.
Simply put, in a hash both are desirable properties. Ideally youur hash should be as
collision resistant as possible. Ideally it should also be resistant to being worked
backward(if every message has a unique hash this can be a problem as far as keeping
the messages secure). However, pursuing any one of them is a bad thing. XORing the
message with a fixed key/ permuting it with a fixed permutation is completely
resistant to collision, but is horribly insecure, and maping all values to 1 of 4
values is very resistant to being worked backward, but has horrible colision
resistance. One must seek to maximize both and remain aware that when it gets down
to it, there are tradeoffs that must occur.
>
>
> There seems to be a weak sense in which an attacker has advance
> information when the hash-size and the message size are equal and he
> knows in advance that the hash is a bijection:
>
> If he wants to find a message that has a particular hash, he knows that a
> message that has that hash exists.
>
> This sense seems rather irrelevant in practice - as an attacker is
> /usually/ trying to find a second message that matches an existing hash -
> not trying to find a message that corresponds to a hash which has no
> corresponding message in the first place.
>
> I have difficulty in seeing any practical problem in this area -
> is this property what you are referring to? Or is there some other
> way in which security and hash collision exclude one another?
>
> I beleieve it is possible to have both - and indeed maximum security
> should generally be accompanied by minimal hash collisions - in order
> to best resist brute force.
>
> : As for block ciphers being so simple and symmetric as to be reversable, I
> : know of at least one that is not, depending on whether you call it a block
> : cipher. [...]
>
> Hmm. Block cyphers are certainly usually reversible. They are rarely
> simple. Sometimes, their inverse function may be computationally
> difficult to determine.
>
> : Surely there is a war of data to have just sufficient collisions
> : to maximize a function as a hash and insufficient reversability to allow
> : its solution.
>
> War? Way? I was not saying that you /should/ build hashes (or one
> hashes) from block cyphers - just that there exist methods of
> doing so.
>
> Hashes need not be easy to reverse - indeed one-way hashes should be
> difficult to invert. The very idea of reversing a hash makes little sense
> anyway in the common case where the message size exceeds the hash size.
> --
> __________
> |im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
>
> Enough research will tend to support your theory.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Linear Congruential Generators
Date: Mon, 13 Dec 1999 08:48:27 -0700
Reply-To: [EMAIL PROTECTED]
Gary wrote:
>
> I think parity is a good idea but the efficiency of the related function
> which requires a loop to result in 1 bit isn't nice.
> The adding (maybe XOR for non linear mix would be better) of 2 LCPRNGs is a
> nice idea and very efficient.
Addition, XOR, and subtraction give the same statistics for k-bit words. The
operation table is a quasi-group (latin square) thus for each input on one
side, all outputs on the other side occur. Overall statistics doesn't change
for each case. Any quasi-group will work as a combiner. If the incoming symbols
do not have uniform distributions, the output will be closer (never equal) to
uniform.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Better encryption? PGP or Blowfish?
Date: Mon, 13 Dec 1999 16:42:31 GMT
In article <831oof$c6g$[EMAIL PROTECTED]>, molypoly <[EMAIL PROTECTED]> wrote:
> Which is a harder encryption to break? The encryption in PGP program
>or McAfee's PcCrypto program which has the 128 bit Blowfish encryption.
>Thanks. You can reply to me at (remove the "nospam")
>[EMAIL PROTECTED]
>
The one thing about PGP is that in its standard mode it ues a "ZERO
knowledge" method so that in theory all the information to break the code is
self contained in the PGP message its self. This means that in theory no
addtional information is needed for groups like the NSA to read what ever file
you carelessly encrypted using this method even if your encrypting a file of
random noise.
But if the PcCrypto program is done correctly and that is a big if. Then
there may not be enough information to break a message on its own when
intercepted by the bad guys assuming you send only one message and pick
a good key.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Why no 3des for AES candidacy
Date: 13 Dec 1999 16:15:00 GMT
Why isn't 3des being considered for the AES? Is it because it is slower than
DES?
------------------------------
From: [EMAIL PROTECTED]
Subject: lfsr based cryptosystem
Date: Mon, 13 Dec 1999 16:31:21 GMT
hi,
i am looking for cryptosystems based on combination of lfsr's.
the only commercial used i know is A5. also there are existing many
educational examples like shrinking, geffe ..
Does anybody know other commercial used cryptosystems based
on lfsr.
references and links would be helpful.
thanks for reading
Wolfgang Wittmann
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Mon, 13 Dec 1999 11:50:50 -0500
UBCHI2 wrote:
> Why isn't 3des being considered for the AES? Is it because it is slower than
> DES?
One good reason:
The AES is supposed to support the following different key sizes: 128, 192, 256
You can see why 3-DES, with it's single sized168 bit key, does not fit in this
categorie.
Anton
------------------------------
From: "Tim Wood" <[EMAIL PROTECTED]>
Subject: Re: The future of telecommunication?
Date: Mon, 13 Dec 1999 16:57:49 -0000
Melinda Harris wrote in message <8325hm$t55$[EMAIL PROTECTED]>...
>Is it possible?? A virus that encrypts your entire hardrive upon logon?
>
>
It generally takes along time to encrypt a hardrive. POH used IDEA to
encrypt a hardrive, but it wasn't a virus. (Although it could be altered).
There are other programs about that do similar things.
I don't really understand the question though.
tim
--
**<Stolen line alert>**
>From my one-bit brain with a parity error.
**</Stolen line alert>**
------------------------------
From: Neil Bell <[EMAIL PROTECTED]>
Subject: Re: Better encryption? PGP or Blowfish?
Date: Mon, 13 Dec 1999 08:55:48 -0800
Does such a snotty and pompous response contribute to his learning??
Does the word "kindness" ever enter into your thoughts?
Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <831oof$c6g$[EMAIL PROTECTED]>,
> molypoly <[EMAIL PROTECTED]> wrote:
>> Which is a harder encryption to break? The encryption in PGP program
>> or McAfee's PcCrypto program which has the 128 bit Blowfish
>encryption.
>> Thanks. You can reply to me at (remove the "nospam")
>> [EMAIL PROTECTED]
>>
>
>You have sucessfully compared apples to oranges and if you don't know
>why, you wouldn't fully understand a proper response anyways.
>
>Tom
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: some questions about DES
Date: Mon, 13 Dec 1999 12:02:04 -0500
>
> How fast and with which computer (price) can DES been broken nowadays ?
You can get this answer by a nice table that is given in an issue of
CryptoBytes,
Volume 3, No.2-Autumn 1997. Get it at
http://www.rsasecurity.com/rsalabs/cryptobytes/
Check out the article "Efficient DES Key Search: An update".
This is exactly what you want.
Anton
------------------------------
From: "Tim Wood" <[EMAIL PROTECTED]>
Subject: Re: Why no 3des for AES candidacy
Date: Mon, 13 Dec 1999 17:05:18 -0000
Anton Stiglic wrote in message <[EMAIL PROTECTED]>...
>UBCHI2 wrote:
>
>> Why isn't 3des being considered for the AES? Is it because it is slower
than
>> DES?
>
>One good reason:
>
>The AES is supposed to support the following different key sizes: 128, 192,
256
>
>You can see why 3-DES, with it's single sized168 bit key, does not fit in
this
>categorie.
of course it's effective key length (strength) is 112bit not 168bit...
>
>
>Anton
>
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Are thermal diodes as RNG's secure
Reply-To: [EMAIL PROTECTED]
Date: Mon, 13 Dec 1999 16:58:56 GMT
Bill Unruh <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] (Lincoln Yeoh) writes:
[removing biases from hardware sources of randomness]
: ]How can we cook such output?
: Eg, if you suspect that the output is not really random, but is
: "partially" random, so that say a fraction f of the information really
: is random,then you could feed say 128/f bits into a hash function like
: MD5 and use the 128 bits of output. That output should be "fully"
: random.
Yes, although you seem to be using "should" in the same sense as in the
sentence:
"The output from a pseudo-random number generator should be fully random."
If any practical hash were as good at distilling entropy as this,
it would be a miracle.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Complex things start life being simple.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: some questions about DES
Date: Mon, 13 Dec 1999 11:47:50 -0500
Tom St Denis wrote:
>
> In article <82tt20$q4u$[EMAIL PROTECTED]>,
> "Buchinger Reinhold" <[EMAIL PROTECTED]> wrote:
> > Hi !
> >
> > I write a paper about DES for my school - leaving exam and I need some
> > further informations.
> >
> > Where was and is DES used ?
> > Has DES been verified in 1998 ?
> > If not what's its succession ?
> > How fast and with which computer (price) can DES been broken
> nowadays ?
> >
> > If you have some references (websites, ...) for your knowledge please
> let me
> > know !
> > I am VERY grateful for you help !
>
> DES in it's original form is no longer used.
That's unfortunately not true. There are good reasons why it should
be, but it is not.
> 3DES is still in use today, primarly in software but some
> hardware for it is out there.
Actually, for software crypto there are a lot more attractive options.
3DES exists for two reasons: (1) it's very easy to do in hardware given
that you've already done DES, (2) it has been very well analyzed.
I've never seen strong crypto chips that didn't do 3DES, but for a lot
of them that's the only strong crypto they do. In particular,
hardware implementations of IDEA, Blowfish, CAST, or similar "second
generation" block ciphers are, at best, rare.
> It can be cracked with 120000 spare computers over the inet in about 20
> hours. [well DES anyways].
More importantly, it can be cracked in about the same time with a
modest amount of dedicated hardware.
paul
------------------------------
From: Glenn Larsson <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Simple newbie crypto algorithmn
Date: Mon, 13 Dec 1999 15:17:34 +0100
Steven Siew wrote:
> That of course is total bullshit. Anyone with basic C programming skills and
> basic high school maths can write a crypto algo that the whole world cannot
> crack in less than 1000 years.
When i was a network tech at my last job, I've met a student who thought
that this
was true too, but when i (a next to amateur with NO relevant math
education) showed
him that his crypto only had 2^16 combinations - he changed his
oppinion.
(Oh yeah; it was also secret algorithm dependant)
It IS necessary to study crypto to get a proper picture on what works
and what
doesn't, this is the same opinion i also get from people who are
"security experts"
but who have never broken into a system or found a flaw in their entire
life.
_Please_ take this into consideration,
Glenn
------------------------------
** 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
******************************
