Cryptography-Digest Digest #474, Volume #9 Tue, 27 Apr 99 21:13:04 EDT
Contents:
Re: break this code ("Dan")
Re: True Randomness & The Law Of Large Numbers (Medical Electronics Lab)
Cryptography FAQ (08/10: Technical Miscellany) ([EMAIL PROTECTED])
Re: DES3 padding (John Savard)
Re: Computing the run time for NFS. (Medical Electronics Lab)
Re: break this code ("Steven Alexander")
Scramdisk 2.02h + Win98 = Can't shutdown to DOS. ([EMAIL PROTECTED])
Re: break this code ("Dan")
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(Sundial Services)
Quantum Computing and Cryptography added to web site... (John Savard)
Re: Factoring breakthrough? (DJohn37050)
Re: True Randomness & The Law Of Large Numbers ([EMAIL PROTECTED])
Re: choosing g in DH (Medical Electronics Lab)
Re: break this code (Nathan Kennedy)
Re: break this code (consalus)
Re: Algorithms where encryption=decryption? (consalus)
Re: Easy identity-proof (NOT Fiat-Shamir) ([EMAIL PROTECTED])
Re: DES3 padding (John Savard)
Re: new method ? ("Steven Alexander")
Re: Quantum Computing and Cryptography added to web site...
([EMAIL PROTECTED])
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
([EMAIL PROTECTED])
Re: Papers on RC4 key size ([EMAIL PROTECTED])
Re: Obvious flaws in cipher design (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: "Dan" <[EMAIL PROTECTED]>
Subject: Re: break this code
Date: Tue, 27 Apr 1999 17:50:20 -0400
Why do you need the entire system, isn't that kind of like cheating?
Please don't take this the wrong way, I just wanted to know.
Dan [EMAIL PROTECTED]
Mike Andrews wrote in message <7g4m8v$8p4$[EMAIL PROTECTED]>...
>Travis Hoover ([EMAIL PROTECTED]) wrote in article
<[EMAIL PROTECTED]>:
>: I am a student at Purdue University, and as a course project, I
>: created my own encryption/decryption program. I was wondering
>: if anyone would be willing to help me out with a little research.
>
>: The above passage is encrypted to the following:
>
>: S&i{,q$}z}rq~x*g|.\'vn{m.a~m"kz#u&}6&i|p0e}&i.o!y|ym.|$stkk$80M*
>: izsm&in&u),!{x&m|o$}zzq}z?hoiz)|&myt(~~!k|gu<,Y$#g{.%!rnkzwzw
>: mp&i|'!ro&!}#|h*hm.%ypvovu,&s*nmz|0qo&w%"0{szp.m0psz|zq0voymo~sl8
>
>: I would like any of you out there to try and break the following
>: encrypted passage.
>
>[snip snap snorum, high cockalorum]
>
>: If you can break this passage, please let me know by 8:00 tonite
>: (Tuesday), and tell me how you did it, how long it took, and what
>: plaintext you got(because you might be wrong!) Thanks for your
>: help. Please either respond to this newgroup or to
>: [EMAIL PROTECTED]
>
>That's not the way it's done here. If you're willing to post your
>entire system (but not the keys) _and_ some ciphertext, then one
>or more of us may have a go at it -- but generally not with a
>deadline of one or two days.
>
>One basic idea behind secure ciphers is that the attacker needs
>both the system _and_ the keys to break the cipher. A measure of
>the security of your system is how closely it approaches that
>ideal.
>
>You might want to look up the difference between "code" and
>"cipher" .
>
>--
>Mike Andrews
>[EMAIL PROTECTED] (when it works)
>
>
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Tue, 27 Apr 1999 12:15:20 -0500
Douglas A. Gwyn wrote:
> *******************************************************************
> * Okay, here is a nice cryptomathematical problem for everyone: *
> * Given that you have to make a decision whether or not a *
> * sequential flat-random bit stream generator is malfunctioning *
> * within 20,000 bits of the point at which it first malfunctions, *
> * what tests would you perform? The generator must be treated *
> * as a "black box"; no knowledge of its inner workings is *
> * available; consequently, the tests must be performed on its *
> * output stream. The upper limit for the likelihood of *
> * malfunction being reported when it isn't present shall be *
> * 10^-6. The goal is to maximize the likelihood of reporting a *
> * malfunction when one in fact is present. *
> *******************************************************************
Autocorrelation and frequency distribution as well as uniformity.
If autocorrelation gets above .1 it's a flag, if uniformity is
unballanced by more than 200 it's a flag and if the frequency
distribution on 8 bit patterns has more than 32 bins missing it's
a flag. 2 flags and I light up an LED, all 3 and I report a full
error.
20,000 bits ain't a whole lot to work with to get 10^-6. I'd
prefer 10^6 bits :-)
Patience, persistence, truth,
Dr. mike
------------------------------
Subject: Cryptography FAQ (08/10: Technical Miscellany)
From: [EMAIL PROTECTED]
Crossposted-To:
alt.gothic,uk.people.gothic,boulder.general,at.test,talk.politics.crypto,sci.answers,news.answers,talk.answers
Date: 27 Apr 1999 00:10:51 GMT
Reply-To: [EMAIL PROTECTED] (Henrietta K. Thomas)
Fuck You If You Aint Goth!!!
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: DES3 padding
Date: Tue, 27 Apr 1999 20:28:19 GMT
[EMAIL PROTECTED] wrote, in part:
>I'm a newbie using DES and have integrated DES3
>into my program. The program basically reads
>a 16 byte block then encrypt it. The problem
>is at the end when there are less than 16 bytes
>of data. I've read abite on padding but can not
>get the last block to encrypt/decrypt correctly?
>eg: last block of data contains 8 bytes
>the end.
>How do I pad the last block? with '0'?? If padded
>what about when I try to decrypt it? do I need
>to pad it with '0' too on decrypt?
You certainly could pad the last block with zero bytes. But then you can't
throw the same number of bytes away afterwards; you have to send the whole
block.
On reciept, there's nothing to pad, since you sent complete blocks.
But then you need a way to trim the trailing zeroes off your plaintext, if
you're handling binaries.
There's another method, called "ciphertext stealing", explained in Bruce
Schnier's book "Applied Cryptography". You wouldn't happen to have a copy
around where you work, by any chance?
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Computing the run time for NFS.
Date: Tue, 27 Apr 1999 12:39:50 -0500
Steven Alexander wrote:
>
> I'm not sure how to compute the run time for the number field sieve and
> would like for someone to confirm this for me. The run time that I have for
> the algorithm is
>
> e^^[O(log^^1/3 n log log^^2/3 n)]
>
> What I'm not sure about is:
>
> Is n the value of the number to be factored, or its length in bits(I've seen
> other problems represented this way)?
> Are the logarithms of base 10 or base 2?
>
> I've been using the value, not the length, of n, and a base of 10. Am I
> correct? I hope that this isn't a dumb question. I just wanted to be sure
> before relying to heavily on any of the numbers that I'm playing with.
> Thanks in advance.
You are correct. Basicly log n is the number of digits if log base 10
is used and the number of bits if log bas 2 is used. log log n is the
nuber of digits or bits in the number log n. It's just an order
of magnitude estimate, so stay consistent in which log you use and
you'll have comparable numbers.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Re: break this code
Date: Tue, 27 Apr 1999 15:05:41 -0700
No. If a system is secure, knowledge of it will not matter. Without the
key, I will not be able to read what is encrypted with it. If your system
is strong, I will be forced to guess every key one after the other until I
get the right one. With a significant key this will be impossible. If you
are really interested pick up "Applied Cryptography" by Bruce Schneier. It
is a great introduction to cryptography. Also, the sci.crypt FAQ will
probably be very helpful to you.
-steven
Dan wrote in message ...
>Why do you need the entire system, isn't that kind of like cheating?
>
>Please don't take this the wrong way, I just wanted to know.
>
>Dan [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Scramdisk 2.02h + Win98 = Can't shutdown to DOS.
Date: Tue, 27 Apr 1999 22:20:57 GMT
All,
I have just replaced scamdisk 2.02c with 2.02h. Now I find
that after using Scramdisk I cannot "restart in MS DOS mode." The
screen goes black as normal, but instead of processing the
autoexec.bat it just hangs, with the cursor flicking in the top left
hand corner.
I know this problem is the rusult of the new Scramdisk. I can
do anything else, and restart in dos works fine. However, after a
fresh boot, if the first and only thing I do is open Scramdisk, then
close it again (I don't even have to open a container), "restart in
Dos" hangs.
Has anyone else experienced similar? Does anyone have any
suggestions other than going back to 2.02c?
Thanks for your time,
JP.
------------------------------
From: "Dan" <[EMAIL PROTECTED]>
Subject: Re: break this code
Date: Tue, 27 Apr 1999 18:30:28 -0400
I have read the FAQ and have a copy of "Applied Cryptography" on the way.
I do agree with the FAQ on many of the issues that I could understand
(remember I am an amature) I especially agree with the part that says
something like one must first learn to break cyphers if he plans to write
good ones.
Can someone clear up one thing for me?
What does the term "XOR" mean? I believe this refers to a type of comparison
but I am not sure.
Dan [EMAIL PROTECTED]
Steven Alexander wrote in message ...
>No. If a system is secure, knowledge of it will not matter. Without the
>key, I will not be able to read what is encrypted with it. If your system
>is strong, I will be forced to guess every key one after the other until I
>get the right one. With a significant key this will be impossible. If you
>are really interested pick up "Applied Cryptography" by Bruce Schneier. It
>is a great introduction to cryptography. Also, the sci.crypt FAQ will
>probably be very helpful to you.
>
>-steven
>
>Dan wrote in message ...
>>Why do you need the entire system, isn't that kind of like cheating?
>>
>>Please don't take this the wrong way, I just wanted to know.
>>
>>Dan [EMAIL PROTECTED]
>
>
>
------------------------------
Date: Tue, 27 Apr 1999 15:30:28 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
[EMAIL PROTECTED] wrote:
> Once you have an "OTP quality stream key" just XOR and go. You
> get perfect secrecy quality privacy and you can do no better.
> If you need provable authenticaiton, use a universal keyed hash.
> Your extra operations are pointless.
I question that, Bryan. It seems to me fairly obvious that you -can-
gain security by doing something more clever than XOR using the stream
key that you've produced.
The XOR algorithm takes exactly two inputs and remembers nothing.
Table-algorithms such as Terry Ritter's patent have quite a long
"memory" indeed.
If you have the stream, using XOR, then there is absolutely nothing more
to be recovered. But why not, for example, "two streams?" "255
streams?" And a combination/mixing algorithm that demands that the
cryptanalyst recover them both, while making it impossible for him to
separate the influence of one from that of any and/or all of the others?
It seems to me, poor layman that I am, that cipher designers are secret
proponents of Zen. They look for the minimal possible approach to the
problem and say "ommmmm...." when there is actually much to be gained by
making the cipher a hemmhoraging profusion of interrelated operations!
A modern-day computer would not even grunt at this task, although an
IC-designer might see stars.
The cryptanalytic mechanisms we have today are computers, not chips.
Why are we still designing "zen ciphers?"
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Quantum Computing and Cryptography added to web site...
Date: Tue, 27 Apr 1999 22:30:01 GMT
I saw an interesting magazine article about the web site
http://www.openqubits.org/
and there I found papers that finally enabled me to say something *useful*
about quantum computing.
So, in the sixth chapter of my site, at
http://members.xoom.com/quadibloc/mi0606.htm
I added a page about quantum computing. But then, although I had not wanted
to explain quantum cryptography, simple though it may be, on the site
(since it isn't really algorithmic: I don't talk about invisible ink on my
site either), since the two topics have the word "quantum" in them, they
are naturally confused, so I'd better explain both to distinguish them...
thus, I surrendered, and added discussions of both topics to my site. Very
brief discussions, and the topics are of course covered better elsewhere.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Factoring breakthrough?
Date: 27 Apr 1999 22:48:49 GMT
I have heard this rumor also, no details yet.
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Tue, 27 Apr 1999 21:56:00 GMT
rcktexas wrote:
> I think we are saying the same thing, namely that some standard
> statistical tests can be used to detect potential error conditions. We
> have said that all along. Now we are saying it is time to decide which
> ones to use, and for what reasons.
There are three requirements: First, good generators must have low
probability of failing the test. We quantify and prove this
probabilty. Second, bad generators should, as often as possible,
fail the test. Mathematical reasoning cannot quantify the
probability, so we choose tests that have in worked well at
rejecting real candidates. Third, the test must be practical to
perform.
> I am taking the position now that I require an expected condition of
> failure to justify the test and not some probabilitsic condition that
> may or may not be caused by an unexpected condition of failure.
Can you offer justification of this position beyond its amusing
nature? Why are the modes of failure you have not identified less
dangerous than those of which you are aware?
> Unless you can relate the test directly to the expected failure mode
> with reasonable certainty, I consider it just more snake oil.
As of now, that's another unjustified conclusion.
--Bryan
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: choosing g in DH
Date: Tue, 27 Apr 1999 12:29:32 -0500
Phil Howard wrote:
>
> Is this something that will explain the mathematics or assume one already knows
> the math? I'm principly looking for resources that explain the math without
> having to take a full course in it. In other words, what is "prime order"?
> If there is any general resource that answers questions like this, that would
> be good to know as I could consult it with my next question. What I am
Any beginning book on number theory will help you.
"Order" of a group is the number of elements it contains. Many
groups have sub-groups depending on the algebra. A group of
"prime order" is one that has a prime number of elements. The
simplest such group is "integers mod p" which means to combine
integers modulo a prime number.
When you take integers to a power mod p, that's a different
group. If the base is a "generator" you will find that every
number in the range 1...(p-1) is computed (in some bizzare
list order).
For DH, you take a generator g and raise it to some power x
doing it mod p. This will give you every value (except 0)
in a group of prime order for all possible values x.
I strongly advise a trip to the library. Number theory is
a ton of fun!
Patience, persistence, truth,
Dr. mike
------------------------------
From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: break this code
Date: Wed, 28 Apr 1999 07:01:36 +0800
> What does the term "XOR" mean? I believe this refers to a type of comparison
> but I am not sure.
It's the single most basic crypto function. It's a Boolean function, you
take two bitstreams, and combine them by emitting a one if the bits differ
and a zero if they are identical.
Nate
------------------------------
From: consalus <[EMAIL PROTECTED]>
Subject: Re: break this code
Date: Tue, 27 Apr 1999 18:38:34 -0500
Quick info on XOR.
XOR is a bitwise operation that is its own inverse.
It is an exclusive OR.
Here is a table of what happens with bits.
======
0 1| 1
1 1| 0
0 0| 0
1 0| 1
My ascii skills are pretty much nonexistant, so I'll try to explain.
Anything xored with itself is 0. 0 xored with 1 is 1.
So.. 5 xor 3 works like this:
011
101
------
110
5 xor 3 then equals 6.
A fun property of XOR is that any ((a xor b) xor b) is always a, no
matter what a or b are. This makes it useful for some encryption.
Hope this helped,
Kyle Consalus
------------------------------
From: consalus <[EMAIL PROTECTED]>
Subject: Re: Algorithms where encryption=decryption?
Date: Tue, 27 Apr 1999 18:45:42 -0500
On a simpler level, because to me it looks somewhat like you are
talking more about operations than you are algoritms, I can think
of two binary operations that are their reciprocal.
Bitwise NOT. This is similar to f(x) = -x, though not the same.
This can be done on a byte with x ^= 0xFF;.
Bitwise rotation. This helps with the avalance effect, and is
cheap on some processors. keep in mind, you must rotate
1/2 the number of bits.
Another angle..
Kyle Consalus
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Easy identity-proof (NOT Fiat-Shamir)
Date: Tue, 27 Apr 1999 20:25:36 GMT
Christian Geuer-Pollmann:
> I need a system used for authentication. Systems like Fiat-Shamir have a
> balance in the computation power: The proof is a little bit hard, the
> verification is easier. For my project, I need a system with an easy
> proof and a harder verification. The proof must be done on a very lousy
> hardware (less computing power than a smartcard and much faster like 1/2
> second).
>
> Do there exist such systems / protocols?
Well, sort of.
First, if you can assume prover and verifier share a secret,
then you can use fast symmetric crypographic primatives.
If you need public key but can do expensive pre-computation that
doesn't count toward the 1/2 second, then El Gamal variants (such
as DSA as Pual Rubin pointed out) can serve.
If you need to optimize the pre-computation too, you can use an
Eliptic Curve (EC) version of ElGamal. Even with all the EC
optimizations (which you'd probably have to licence from my
employer, Certicom), the pre-computation would take more than
1/2 second on a sub-smartcard processor. We can get down to
about a second per signature on a typical smartcard.
The remaining option is some variant of the "one-time" signature.
One-time signatures are fast, but have the disadvantage that the
key gets used up by producing signatures. The signer would need
on the order of half a kilobyte of key material for each signature,
subject to size-speed tradeoffs. Of course if you can store pre-
computed material, you could do the same for ElGamal. One-time
signatures are often attractive in hybrid schemes; every so often
you can use a true public-system to sign a bunch of one-time
verification keys.
--Bryan
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: DES3 padding
Date: Tue, 27 Apr 1999 20:31:09 GMT
[EMAIL PROTECTED] wrote, in part:
>please reply to [EMAIL PROTECTED]
Or is this simply a prank posting, designed to discredit a certain Calgary
firm...
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Re: new method ?
Date: Tue, 27 Apr 1999 13:12:21 -0700
An Irish girl has supposedly found a method using matrices that is faster
than RSA and provides the same security. However, I haven't seen the work
myself so I don't know if it is less secure, more secure, faster,
slower...etc. It isn't supposed to be a new system, just faster RSA.
-steven
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Quantum Computing and Cryptography added to web site...
Date: 28 Apr 1999 00:03:23 GMT
Reply-To: [EMAIL PROTECTED]
You could also include a blurb on brute-force searching, quantum computers
and the quantum search algorithm (it is named after someone, but i forget
it).
A lot of people misunderstand how quantum computation works and assume
that since you can run through all the possibilities at once then you can
brute-force a key in one turn of the crank. Unfortunately, it doesn't work
that way. As you mention: "However, it could only give us one of the
solutions when it finishes." The other important fact to remember is that
_which_solution_you_get_is_randomly_selected_. So, you try every possible
key on a given ciphertext and *one* of them does indeed produce your known
plaintext, but then you make a measurement on the system and just find
that the key "SDKR@#$%N@#$KJ" decrypts the ciphertext to "@#$@K#N$JF" and
you didn't learn anything. The trick comes in that while the solution you
get is randomly selected, you can bias the selection in favor of the solution
which you are looking for. This gives you a speedup from the O(N) classical
case to O(sqrt(N)) on a quantum computer. The result is that you need
N^2 more key possibilities in your cipher so that you need twice the number
of bits in your key (512-bit ciphers being cracked by a quantum computer are
equivalent to 256-bit ciphers being cracked by classical computers -- assuming
equivalent "clock speeds", which you probably can't assume...).
The speedup from O(N) to O(sqrt(N)) is provably the best you can do, provided
that you don't know anything else about the distribution. In crypto terms
this means that you've got a perfect algorithm that won't leak to the attacker
any information. If you can get some information, though, which gives you
more leverage over predicting which of those solutions might be the right
one, then the distribution is no longer flat and the quantum computer might
be able to brute force it much faster. All hypothetically, of course.
Dunno, I think that's some "useful info" -- good to show to people who claim
that quantum computation means the death of cryptography, and people who
don't understand the way that quantum paralellism works.
[EMAIL PROTECTED] (John Savard) writes:
>I saw an interesting magazine article about the web site
>
>http://www.openqubits.org/
>
>and there I found papers that finally enabled me to say something *useful*
>about quantum computing.
>
>So, in the sixth chapter of my site, at
>
>http://members.xoom.com/quadibloc/mi0606.htm
>
>I added a page about quantum computing. But then, although I had not wanted
>to explain quantum cryptography, simple though it may be, on the site
>(since it isn't really algorithmic: I don't talk about invisible ink on my
>site either), since the two topics have the word "quantum" in them, they
>are naturally confused, so I'd better explain both to distinguish them...
>
>thus, I surrendered, and added discussions of both topics to my site. Very
>brief discussions, and the topics are of course covered better elsewhere.
>
>John Savard ( teneerf<- )
>http://members.xoom.com/quadibloc/index.html
--
Lamont Granquist ([EMAIL PROTECTED])
ICBM: 47 39'23"N 122 18'19"W
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Tue, 27 Apr 1999 21:03:10 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> In article <7fusfv$as8$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bryan G. Olson;
> CMSC (G)) wrote:
>
> >
> > There is a situation worse than having all one's eggs in one basket.
> > The problem with one basket is that there exists a potential failure
> > that would be catastrophic. What's worse is a system in which any
> > one of many possible failures would be catastrophic. If one accepts
> > that in realistic applications of cryptography the same intelligence
> > is available from many messages, then choosing from a thousand
> > ciphers for each message moves us from one potential catastrophic
> > failure to many potential catastrophic failures.
>
> With some effort, but it could be completely automated, using several
> algorithms, it is reasonable to maximize security available not by living
> in fear of the weakest algorithm but working to make sure the strongest
> was included.
I'm talking about Ritter's suggestion in which the protocol
chooses one of about 1000 ciphers at random for each message.
It's not enough to include strong ciphers in the pool.
> Consider the following key handling scheme: A OTP quality stream key is
> converted to a number of complementary keys
[...]
Once you have an "OTP quality stream key" just XOR and go. You
get perfect secrecy quality privacy and you can do no better.
If you need provable authenticaiton, use a universal keyed hash.
Your extra operations are pointless.
--Bryan
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Papers on RC4 key size
Date: Wed, 28 Apr 1999 00:07:26 GMT
> No deep analysis is needed here. A 40 bit key takes, worst case, 2^40
> operations
> in a brute force search. That's not a particularly big number.
> Therefore,
> ALL cryptosystems with 40 bits keys are useless.
Not really, what if a key is generated at random, and the secret is valid for
say the next 5 minutes. Can you search 2^40 keys in 5 minutes?
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: Obvious flaws in cipher design
Date: Wed, 28 Apr 1999 00:12:41 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Sandy Harris) wrote:
> [EMAIL PROTECTED] (Jaime Suarez) writes:
>
> >Let's say that I am an amateur cryptographer and have written -just for the
> >fun of it- an algorithm. I would like the group to explain me their 'top ten'
> >reasons to see that it has obvious flaws. For example looking only at the
> >output it shouldn't compress very much, right?
>
> It shouldn't compress at all. It should be indistinguishable from
> random noise. Any pattern is a weakness.
>
actual since most good encryptions programs encrypt file "A" to "B"
if "A" is ascii text then file "A" should be compressible and file
"B" should usually not be compressable but it might be.
Or you could with many good routines start with a "B" which is
Ascii text that is most likely compressable then decrypt the file
and get an "A" files which usually is not cmpressable to a smaller
file. The word "all" is overused in many descriptions so be
careful.
> > or maybe change some bits of the input and see how the output comes out?
>
> For a block cipher, change one bit of either input or key and about
> half the output bits should change. This should be true after far
> fewer rounds than the actual cipher uses.
>
Again this is not always true.
> For a stream cipher, changing one bit of key should change the
> output a lot also.
>
> > And what should I avoid in the algorithm itself?
>
> Look at the sizes of everything. In a block cipher, block and key
> should both be large enough to prevent the enemy attacking
> with large tables. Current generation mostly have 64-bit block,
> 128-bit key.
>
Take a look at scott16u or scott19u when you start comparing
things you may be surprised.
> Any password or passphrase used should have adequate
> size, should not be stored or transmitted unencrypted, and
> should be hashed before use.
>
Actually Hashing is a bad idea since it usually reduces
the size of the effective key.
David Scott
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** 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
******************************
