Cryptography-Digest Digest #346, Volume #10 Fri, 1 Oct 99 16:13:02 EDT
Contents:
Re: Are small block sizes less secure? (Jim Gillogly)
Re: Irish schoolgirl wins European Young Scientist Award (Jerry Coffin)
on linear keyspaces (Tom St Denis)
Re: New Export Regulations (Mok-Kong Shen)
Re: Irish schoolgirl wins European Young Scientist Award (Robert Scott)
Re: security: stream cipher (Enterrottacher Andreas)
Re: EAR Relaxed? Really? (Bill Unruh)
Re: hidden channel in Peekboo (Tom St Denis)
Re: Cryptanalysis of 2 key TDES ("Richard Parker")
Re: factoring with quadratic sieve (Bob Silverman)
Re: hidden channel in Peekboo ("karl malbrain")
Re: Ritter's paper (Tim Tyler)
NEW DATA SCOTT19U CONTEST (SCOTT19U.ZIP_GUY)
Re: Cryptanalysis of 2 key TDES (David Wagner)
Re: Ritter's paper (Tim Tyler)
Quantum Crytography (Arthur Dardia)
Re: EAR Relaxed? Really? (Greg)
Re: RC5 Hardware? ("Roger Schlafly")
Re: Comments on ECC ([EMAIL PROTECTED])
Re: NEMA, Swiss cipher machine ("Douglas A. Gwyn")
Re: Example of a one way function? (Patrick Juola)
Re: msg for Dave Scott (Tom St Denis)
Re: New Export Regulations (Greg)
----------------------------------------------------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Are small block sizes less secure?
Date: Fri, 01 Oct 1999 17:06:07 +0000
"Thomas J. Boschloo" wrote:
>
> This would probably be a very simple question to answer, but would a 256
> bit 8 bit block cypher be less secure than an 256 bit, 128 bit block
> cypher?
A 256 bit key, 8 bit block cipher in ECB mode is equivalent to simple
substitution, so it can be broken easily with ciphertext only for fairly
short messages. The "code book" threat decreases as the block
size gets longer.
--
Jim Gillogly
10 Winterfilth S.R. 1999, 17:01
12.19.6.10.8, 8 Lamat 16 Chen, First Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Irish schoolgirl wins European Young Scientist Award
Date: Fri, 1 Oct 1999 12:17:49 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> As you said, the filing date is all that is relevant to who wins the
> patent.
That depends on the country -- it's true in some places (e.g. Japan)
but not others (e.g. the US). In the US, if you can show that you
were the first to invent, you get priority. For example, in some
cases people have obtained patent rights based on their notes in
engineering notebooks.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: on linear keyspaces
Date: Fri, 01 Oct 1999 18:12:32 GMT
Ok I think some mass confusion has gone around about this compress/encrypt
stuff.
Assuming with the current attack the keyspace is linear, you still have to
search on avg 1/2 of the keys before you find the right one. I could for
example give you
12345678 = Ek(ABCDDCBA)
And you would have to search about 1/2 of the keyspace before you found it.
So really it doesn't matter what compression you use. Even if it's
one-to-one I could expect to find the key in the same ammount of time.
And another thing is that if your routines are 'functions' (i.e reversible)
then you can still look for patterns in the output. I could for example look
for words or structured grammer in the output and not just ascii text. It's
not hard, just takes linearly more time. So you might make the keyspace
x(2^n) instead of just 2^n by using one-to-one, but I can simply add log2(x)
bits to the key and use my current method.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: New Export Regulations
Date: Fri, 01 Oct 1999 19:04:13 +0200
Mark Rosen wrote:
>
> Basically, can we now export the domestic version of Kremlin -- the full
> strength version that uses 160 bit Blowfish w/ CBC -- from the US? Do we
I don't yet understand why most US crypto software manufacturers
don't follow the example of PGP.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Robert Scott)
Subject: Re: Irish schoolgirl wins European Young Scientist Award
Reply-To: [EMAIL PROTECTED]
Date: Fri, 01 Oct 1999 17:09:31 GMT
On Thu, 30 Sep 1999 11:34:39 +0300, "Lassi Hippel�inen"
<"lahippel$does-not-eat-canned-food"@ieee.org> wrote:
>
>Stinks a bit. You get the patent protection as soon as the application has been
>_filed_. No need to delay publication till it's granted.
>
>In fact, you'd better publish the application as soon as the papers have been filed,
>because it makes the idea "previous art" for competitors. It guarantees that noone
>else in any other country can file an application, even if they had invented it
>independently.
As you said, the filing date is all that is relevant to who wins the
patent. But there is a reason not to publish before the patent is
granted. If, for some reason, the patent is refused, then secrecy is
the only remaining means of protection. If you published before
the patent was granted then you threw away that option.
Bob Scott
Ann Arbor, Michigan (email: rscott (at) wwnet (dot) net )
(My automatic return address is intentionally invalid.)
------------------------------
From: Enterrottacher Andreas <[EMAIL PROTECTED]>
Subject: Re: security: stream cipher
Date: Fri, 01 Oct 1999 18:58:53 +0100
[EMAIL PROTECTED] schrieb:
>
> Can anyone help me:
>
> There is a concept to implement a stream cipher
> with LFSR to encode. (f.e. Geffe or Alternating
> stop-and-go generator)(with a enough long period)
> The output of the PRSG and the Data Stream are
> then xored.
>
> The problem is, that the Data Stream consists of
> a bitframe in which part of the data (header) can
> be known or puzzled.
>
> Therefore an attacker can get part of the key.
>
> Probably a method is to encrypt the header before real
> encryption.
Or not to encrypt the header at all.
But even then the attacker may know other parts of the
data stream.
But the attacker doesn't get parts of the key (this
would be the internal state of the generator) but only
parts of the output.
The Geffe generator uses three LFSRs. All of them are
clocked.
Now one of them is used to select one of the other
generators that produces the output.
If you don't know the state of the first generator you
don't know what generator produced the output.
The idear of all these stream ciphers is to hide the
internal state of the LFSRs even if the attacker knows
the plaintext and this way the keystream.
> //
> Is it generally possible to encrypt at stream mode
> non random data with a key, which length isn't endless.
Surely it is. The strength of a stream cipher is defined
by the amount of computer power necessary to reconstruct
the internal state only knowing the output of the stream
cipher.
Andreas Enterrottacher
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: talk.politics.crypto
Subject: Re: EAR Relaxed? Really?
Date: 1 Oct 1999 18:30:03 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (wtshaw) writes:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny
>Bravo) wrote:
>> They have the evidence. There is plenty of evidence, and it can't be
>refuted
>> since the methods used to obtain that evidence aren't required to be
>disclosed.
>Disclosing how the evidence was obtained is important to prove that all of
>it was obtained legally. Especially, it is important in crypto to prove
>techniques, to see that a true method was used other than creative
>miscorrelation of data, or improper methods clearly denied.
In this case it is more so. The claim the police would make is that a
certain cleartext is the decryption of a certain encrypted text. The
encrypted text can be tied to the defendant. The clear text contains the
criminal bahaviour of which the defendant is accused. The two Must be
tied together in the chain of evidence. To argue that a law which stated
that the two need not be linked at all except under the say so of a
police officer would not be laughed out of any court in the land is to
have an unduely cynical view of the courts.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: hidden channel in Peekboo
Date: Fri, 01 Oct 1999 18:21:19 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> There are shades here worth mentioning. The problem you brought out was
> that 64 bits could be used to some unuser unfriendly purpose, courtesy of
> a change in the program. To prevent this from causing problems, come up
> with a test if you can to demonstrate the possible hanky panky.
Well you could make peekboo check to see if one of the 32-bit words is a
valid time. However that adds to the code and I really don't want to do it.
The only way to get the bits in the salt is if you have the shared key.
Someone could modify and distribute a copy of peekboo that copies parts of
the private key into it... I guess you will have to get the source and do
your own builds if you are paranoid or use my binaries off the page.
The same argument can be twisted into saying 'what says peekboo doesn't just
use some silly password and ignores the password given'. Again same
response.
> >
> > I don't expect most users to say 'ha he uses blah blah blah' it must be
> > secure. What I want is crypto people to say 'ha he uses blah blah blah this
> > way ...' it must be [unproven to not be] secure. If like GM I can get
> > 'quotes from experts' then that will please the mass.
>
> It appears that some that you might see as experts does not guarantee that
> they also have scruples. Show me a list of bonded experts, particularily
> those that traffic in high dollar advice. Claiming to be at no risk for
> the bad advice you may give at a premium is no good.
>
> One thing the masses are used to is being lied to; treating all like sheep
> rather than working hard to make matters self evident is not really
> helpful. Remember, government rather favors as few people learning much
> about crypto as possible; where do you stand on this?
I never said Schenier had to read my source. I asked if 'anybody' could.
Even if you took 30 mins looking it over and left something in the guestbook
for others to see I would be happy. I agree only relying on 'experts' can be
dangerous (i.e go in to get the tires rotated and come out with a 600 dollar
bill...).,
There are many things in government I don't agree with. I personally don't
believe in government. I wish people would (in Canada for example) have
spines and stand against MP's and elected officials they don't agree with,
but at the same time provide positive alternatives. A lot of the times we
say 'oh well what are you going todo about it' , heck even the french have
the saying 'comme ci, comme ca'....
Anyways... if anybody could just look at the source or binary and sign the
guestbook I would be happy =)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis of 2 key TDES
Date: Fri, 01 Oct 1999 17:46:33 GMT
Jerry Leichter <[EMAIL PROTECTED]> wrote:
> So replacing XOR'ing before and after DES (DESX) with DES
> encryption (2-key Triple DES) only gains you a factor of 4 in security!
Based on key length one might naively expect 184-bit DESX to be
stronger than 112-bit two-key triple-DES. The fact that 112-bit
triple-DES is four times stronger than 184-bit DESX could be
interpreted as a weakness of DESX.
> Assuming I'm interpreting this right - it would require a careful
> comparison of the attack models in the two papers - there's very little
> reason to use triple-DES:
I would agree that two-key triple-DES is probably not the best choice.
On the other hand, 168-bit three-key triple-DES is much stronger than
184-bit DESX. The best known attack against 3DES is a meet-in-the-
middle attack which requires 2^112 operations. With enough known
plaintext DESX can be broken using significantly less operations.
-Richard
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: factoring with quadratic sieve
Date: Fri, 01 Oct 1999 17:45:59 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> i found it in factor.c/initv()/line1078 of the miracl sources.
> with d = number of digits (radix 10) of the number to factor
>
> if d > 20 use a factor base of (d^4)/4096 elements
No. This is about right for d = 60, but is a factor of 2 too
small for d = 70 and gets worse after that.
> if d >= 8 && d <= 20 use a factor base of 25 elements
> if d < 8 use a factor base of d elements
For numbers this small, it doesn't matter too much.
See my paper in Math. Comp.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: hidden channel in Peekboo
Date: Fri, 1 Oct 1999 11:00:47 -0700
wtshaw <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
(...)
> One thing the masses are used to is being lied to; treating all like sheep
> rather than working hard to make matters self evident is not really
> helpful. Remember, government rather favors as few people learning much
> about crypto as possible; where do you stand on this?
This is total PATRONIZATION, an ENEMY of the people in the BOLSHEVIK
schemata. Karl M
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Ritter's paper
Reply-To: [EMAIL PROTECTED]
Date: Fri, 1 Oct 1999 18:29:06 GMT
[EMAIL PROTECTED] wrote:
: Once one has a way to specify truly different ciphers based on extra key
: bits, one could - by doubling the blocksize, and making the cipher used to
: encipher one half depend on the contents of the other half of the block -
: make the choice of cipher for a particular block data-dependent.
It seems that when using a PRNG as a stream cypher, it would be a
good idea if possible to use the contents of the message as an additional
source of entropy, (in addition to the key).
In other words, rather than keeping the PRNG insulated from the message,
you should allow these two entities to interact.
I wonder what the best way of doing this is which retains the ability to
decrypt the information is.
It appears that if decryption happens in a largely serial manner,
entropy from early (decrypted) parts of the message should be available
to feed into the PRNG as it decrypts later parts of the message.
Thoughts in this general area would be welcomed.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Where you go depends on how you look.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: NEW DATA SCOTT19U CONTEST
Date: Fri, 01 Oct 1999 19:11:37 GMT
Well folks if you haven't seen my gloat contest it is
a contest that shows how crappy the AES with 3 letter
chaining methods are. Because if any one had the balls
to offer a similar contest with any of the weak AES methods
using the blessed chaining methods the solution would be
trival. If you want check it out your self or stay ignorant.
Any way the next nibble of solution is at my webstie
so there is only 32 bits left unknown. The solution should
be in easy reach at this point for anyone with a PC.
So give it a shot you might leatn something.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Cryptanalysis of 2 key TDES
Date: 1 Oct 1999 11:43:15 -0700
In article <[EMAIL PROTECTED]>,
Jerry Leichter <[EMAIL PROTECTED]> wrote:
> That's an astounding result: Killian and Rogoway show that a brute-
> force attack against DESX with t known - in fact, even chosen -
> plaintext/ciphertext pairs requires 2^(118 - lg(t)) DES encryptions and
> decryptions. So replacing XOR'ing before and after DES (DESX) with DES
> encryption (2-key Triple DES) only gains you a factor of 4 in security!
Be a little careful in how you interpret the Kilian and Rogaway result.
And be a little careful in separating two-key 3DES from three-key 3DES.
I don't think that your conclusion ("there's very little reason to use
triple-DES") is warranted.
K&R worked in a rather unusual model, and as a result were only able to
show proofs of security against pure keysearch attacks. And, in fact,
DESX does not have the security level you'd expect from Triple-DES: it
is susceptible to a differential attack requiring something on the order
of 2^60 chosen texts, and presumably susceptible to a linear attack
requiring even fewer known texts. It is clear that only adding whitening
can't help much against differential or linear cryptanalysis.
Second, the attack against two-key 3DES that you mentioned above doesn't
apply to three-key 3DES. So, as far as we know, three-key 3DES is vastly
more secure than DESX, not only against differential/linear attacks, but
also against exhaustive keysearch attacks.
Therefore, I still think there's plenty of reason to use three-key 3DES.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Ritter's paper
Reply-To: [EMAIL PROTECTED]
Date: Fri, 1 Oct 1999 18:17:52 GMT
Johnny Bravo <[EMAIL PROTECTED]> wrote:
: On 30 Sep 99 03:38:21 GMT, [EMAIL PROTECTED] () wrote:
:>Although the AES candidates are excellent ciphers, the fact that they
:>are, in terms of their key size and block size, merely one step beyond
:>DES, rather than two or three steps beyond
: 256 bits is not 4.5 times as secure as 56 bits. It is exactly 115,792,089,
: 237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,
: 511,950,319,091,712,000 times as secure. This is a bit more than one step
: beyond DES.
256 bits of key may not be /that/ much stronger.
Your mathematics depends on the assomption that the security of a cypher
depends linearly on the size of its keyspace. As few cyphers are broken
by brute force searches through all the possible keys, it really is
unlikely to be valid to conclude that increasing the size of the keyspace
increases the security in direct proportion.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Girls seldom show dimples to boys who have pimples.
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Quantum Crytography
Date: Fri, 01 Oct 1999 14:50:05 -0400
A very cool article on Quantum crytography. Makes you think.
http://www.newscientist.co.uk/ns/19991002/quantumcon.html
I highly suggest reading it.
--
Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: EAR Relaxed? Really?
Date: Fri, 01 Oct 1999 19:32:42 GMT
> Disclosing how the evidence was obtained is important to
> prove that all of it was obtained legally.
WE KNOW! Now look at what Reno said.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: RC5 Hardware?
Date: Fri, 1 Oct 1999 10:51:43 -0700
ȫ���� <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Has anybody seen a RC5 hardware implementation?
> As for me, not yet.
> If they don't usually make it, why is that?
They don't usually make it because (1) RC5 has been superceded
by RC6, (2) RC5 was more of a research cipher, and (3) RC5 is
patented. There are other more attractive alternatives for
hardware implementation.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Comments on ECC
Date: Fri, 01 Oct 1999 19:33:45 GMT
Jeffrey Goldberg wrote:
> If we have a
> problem which is known to be P, it is still possible that the best
> algorithm *that we know of* for solving the problem is still NP.
No, NP is not a possible property of an algorithm.
NP is a set of sets of strings. My guess is that you
meant super-polynomial time (on a DTM).
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NEMA, Swiss cipher machine
Date: Fri, 01 Oct 1999 19:00:33 GMT
[EMAIL PROTECTED] wrote:
> Yes, but I would presume it is of some relevance how the
> periodicity is combined with the plaintext stream.
True for cryptanalytic purposes, but just knowing that a
machine has wired rotors isn't enough to answer that question.
> In a Hagelin lug and pin machine, the pinwheels produce a sequence of bits
> with a long period, which the cage then, by its lugs, encodes by means of
> an OR function to a displacement; this displacement, once produced, is
> applied to the plaintext by shifting a reversed alphabet.
Hageleins are "key generator" systems, which means that certain
lines of attack are possible that would be ineffective for other
systems.
> In a Lorenz Schlusselzusatz, two banks of pinwheels produce bits that are
> applied by an XOR to a stream of teleprinter characters.
Ditto.
> But in a rotor machine, while the mechanical rotor displacements are
> applied directly by a Caesar substitution - twice, once added, once
> subtracted - the plaintext is also constantly being put through one
> scrambled alphabet after another.
These are not KG systems, so different attacks are used.
For example, some like Enigma have "fast moving" and "slow"
wheels, which allows the analyst to separate out their
distinct effects (using Friedman squares, etc.).
> Of course, by noting how the plaintext is transformed as the
> distinguishing feature, I might come to the bizarre conclusion that
> SIGCUM, a telecipher machine that produced a stream of bits to XOR with
> the plaintext by means of wired rotors, is "not" a rotor machine.
That's the sort of consideration that leads me to think that
one doesn't want to categorize systems too much based on the
technology (rotors) used.
> wired rotor machines are distinguished from other known designs by their
> use of multiple mixed alphabets in successive encipherment stages. This
> cannot be entirely without significance.
I think the way to put it is that successive positions use
related mixed alphabets, where the relation has a certain
character due to the underlying implementation. There are
other systems that fit this description, but the character
is different when a non-rotor-like method of changing the
mixed alphabets is used.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Example of a one way function?
Date: 1 Oct 1999 15:00:06 -0400
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
>Patrick Juola <[EMAIL PROTECTED]> wrote:
>: In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
>:>Boris Kolar <[EMAIL PROTECTED]> wrote:
>:>: Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
>:>:> Boris Kolar <[EMAIL PROTECTED]> wrote:
>:>:> : Roger Carbol <[EMAIL PROTECTED]> wrote in message
>
>["one way" functions]
>
>:>:> I think you need to invoke complex numbers, or modulo arithmetic,
>:>:> or *something* if you want to claim multiplication as a one-way
>:>:> function.
>:>
>:>: No. Multiplication of complex numbers is easily invertible.
>:>
>:>No. a x i = -1. What is a?
>
>: Isn't this a bad example? a == i, of course. I think what you meant
>: is that a * a = -1, which (of course) has two solutions.
>
>You're right, on both counts.
>
>:>Multiplication of complex numbers and modulo multiplication are examples
>:>of "completely" one-way functions that *destroy* information - and have
>:>no unique inverses.
>
>: Again, this is incorrect -- there's a unique inverse for every element
>: (mutter mutter except zero) in any field -- that's part of the
>: definition of field.
>
>: Or, alternately : a * 3 = 1 (mod 7)
>
>: If your cryptographic system isn't set up so that 5 and 12 produce
>: different values, then the information destroyed is irrelevant and
>: immaterial -- and in the complex plane (a * a = -1, solve for
>: i, and it doesn't matter if you get the sign right) multiplication
>: is indeed easily invertable.
>
>To paraphrase your reply, if you ignore the information lost by 5 and 12
>mapping to the same value in your example; and you don't care about the
>non-uniqueness of multiplication of complex numbers, then multiplication
>in these instances is invertible...?
>
>I'm sorry if I still prefer the story the way I told it.
It's not a question of the way you tell the story -- it's the way
you design the cryptosystem.
For example, in RSA, all the multiplications and exponentation (which
is just multiplication with a 'tude, after all) is done modulo a
finite number -- and the cryptographic problem is to break the field
structure.
There are actually lots of numbers that would produce the same plaintext/
cyphertext mapping -- but all of them (except for one pair) involve
numbers greater than the size of the field. So there's a tremendous
potential loss of data in RSA encryption -- but it doesn't matter because
the information lost is also explicitly thrown away in the algorithm
itself.
-kitten
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: msg for Dave Scott
Date: Fri, 01 Oct 1999 19:06:45 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> In article <7t1818$3sh$[EMAIL PROTECTED]>, Tom St Denis
> <[EMAIL PROTECTED]> wrote:
> >
> > In peekboo 1.4 to 1.52 10 blocks is either 10 bytes (RC4), 80 bytes or 128
> > bytes. Most messages are about 512 bytes, so they are eitther 512 blocks, 64
> > blocks or 32 blocks... sorry for the confusion... =)
> >
> I does work to your advantage the stay somewhere under some sort of limit
> of size per message. However, you have only just begun, as a better class
> of algorithm should be able to handle considerable volume per key without
> fear.
>
> Still, for short exchanges in frequently changing keys, many slgorithms
> are successful with that approach. One should never let the shadow of
> Shannon's theories, be the math somewhat difficult to tie down, be
> neglected when dealing with marginal ciphers.
>
> If you can better your cipher's length handling abilities, please do. I
> usually offer something like 5 or 10K characters for room for single
> messages as a default, sometimes much more.
> --
> Still a good idea from Einstein: If you can't explain something clearly to a child,
>you do not understand it well enough.
>
> So much for models of trust, they generally are ill-founded.
Well I use new keys for each message. I think the block ciphers would be
more secure (theoretically) because if you get the same salt twice with say
RC4 you could do some analysis. Each message in peekboo is under 8KB (soon
to change when I add LZRW1 compression).
I don't think people will see the same salt ever, just because there are so
many of them. Of course if you are paranoid (or just don't want to use a
stream cipher) you can use Twofish like I do.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: New Export Regulations
Date: Fri, 01 Oct 1999 19:56:05 GMT
> I don't yet understand why most US crypto software manufacturers
> don't follow the example of PGP.
I concur. But if you look at Microsoft, for example, how
can they start an overseas operation for the purpose of
developing a crypto standard and then expect to remain in
the graces of the US government?
Bill Gates, for example, has found that compromising our
privacy is a small price to pay when international markets
and their enormous profits are at stake.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
