Cryptography-Digest Digest #348, Volume #12 Thu, 3 Aug 00 11:13:01 EDT
Contents:
Re: Small block ciphers (SCOTT19U.ZIP_GUY)
Re: Software package locking (Jeffrey Williams)
Re: IV for arfour ("Andreas Sewe")
Re: Are You seen my two attachments ? (Runu Knips)
Re: OTP using BBS generator? (Mark Wooding)
Re: OTP using BBS generator? (Mark Wooding)
Re: New block cipher for the contest (Runu Knips)
Re: OTP using BBS generator? (lordcow77)
Re: A non-linear extension of the Hill cipher (Mok-Kong Shen)
Re: OTP using BBS generator? (Terry Ritter)
Kill my Cipher ("Martin 'SirDystic' Wolters")
Re: Elliptic Curves encryption (Mark Wooding)
Re: Sending Messages in Morse Code (John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Small block ciphers
Date: 3 Aug 2000 12:55:33 GMT
[EMAIL PROTECTED] (Mack) wrote in
<[EMAIL PROTECTED]>:
>>Mack <[EMAIL PROTECTED]> wrote:
>>> David Wagner wrote:
>>> >(I take it you are intending these things for use as internal
>>> >components of a cipher, in which case they are more properly called
>>> >S-boxes. The word "block cipher" is probably best reserved for the
>>> >externally visible functionality, not the internal invisible
>>> >components.)
>>>
>>> No I am not talking about s-boxes. I am talking
>>> about small block ciphers. s-boxes fall into two
>>> categories static and dynamic (key dependent).
>>> The dynamic version certainly fills the bill as
>>> a cipher. The static version does not.
>>
>>I _still_ think that you are talking about key-dependent S-boxes,
>>and _not_ ciphers. If your object is just part of a larger cipher
>>design and should not be used on its own for encrypting traffic,
>>then calling it a block cipher only invites confusion.
>>
>
>Yes I am interested in key dependent s-boxes. However I am also
>interested in scaling small block ciphers to larger sizes. In that
>case they could be more properly called scalable block ciphers.
>I think the theory of both can be linked at some level. And at an
>even higher level it is simply the theory of permutation generators.
>
>>> If you could point me to some good literature on
>>> fast 'secure' dynamic s-box design that might prove
>>> useful. By secure I mean no attack better than
>>> brute force or dictionary attack.
>>
>>You are right that much of the literature focuses on non-key-dependent
>>S-boxes. But you can still learn a lot from that literature. You
>>should, at the very least, go read the definitions of the various
>>avalanche properties, completeness properties, nonlinearity,
>>correlation-freedom, etc., and their theory. Also, read about bent
>>functions. Those are all relevant to design of key-dependent S-boxes,
>>even if they are stated in terms of non-key-dependent S-boxes in the
>>literature.
>
>I have spent a lot of time reading the literature on just such things.
>I don't yet have copies of the most recent Crypto and Eurocrypt
>though, really have to go read them at the library.
>
>>
>>As for specifically key-dependent S-boxes, Blowfish, Twofish, and Khufu
>>are good starting points.
>>
>
>You could have included skipjack as well. Its problems were with the
>global structure not the s-boxes.
>
>>Finally, let me state my opinion that your definition of `secure' is
>>likely to be too restrictive. Do you have any justification for your
>>definition?
>
>Certainly any cipher has the goal of being secure by my definition.
>If we use a cipher as an S-box then it may not need the same level
>of security. But if we use a smaller cipher and expand it in some
>manner then we definitely need the security.
>
>>I think you can build secure ciphers out of S-boxes that aren't
>>perfectly indistinguishable from random functions; and you can build
>>insecure ciphers out of perfect S-boxes. You need to know what you are
>>going to use the S-box for, and then understand what properties are
>>required, and then try to design a S-box construction that meets those
>>properties.
>>
>
>I gave an example of secure and insecure ciphers built at random (coin
>tossing) in another brach of this thread.
>
>Any good s-box will have certain criteria that it must meet. The ones
>you listed
>are a good starting point. One more criteria that should be listed is
>that the s-box not interact with the cipher in such a was as to reduce
>complexity.
>
>I posted an example of a 8-bit cipher using the S-box from SQUARE
>recently. It used a very simple key structure and as such could
>probably be broken by some form of related key attack. While working
>with various key schedules I found that the S-box interacted badly when
>used in various ways. Specifically when I substituted key bytes
>through the S-box in various ways. I haven't analysed it any further,
>but it hows that even 'perfect' s-boxes are not always perfect.
>
>>
>>
>
>
>
>Mack
>Remove njunk123 from name to reply by e-mail
>
Have you looked at the key dependent S-block ciphers
scott16u and scott19u?
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS **no JavaScript allowed**
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 ** JavaScript OK**
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Subject: Re: Software package locking
Date: Thu, 03 Aug 2000 07:57:09 -0500
"Trevor L. Jackson, III" wrote:
> ...snip...
> One cannot stop an attacker indefinitely. But one can stop any attacker for a day,
> perhaps a week. All but "national technical means" for a week or a month. All but a
> serious software lab for several months. And your average software jockey for many
> months, perhaps several years.
>
> How deep do you want to bury the application under layers of security? Note that it
>is
> pointless to cause the attacker more trouble than writing the application from
>scratch
> would cost. This is why 97DES is a nonstarter. The benefit is not worth the cost.
Good enough. We do seem to be in reasonable agreement. I think the intended audience
has a
lot to do with security requirements. If it's something that might be of interest to
script
kiddies, you might be surprised at the resources that could be directed, albeit in a
somewhat chaotic manner, at the protection scheme. I'm always amazed at the number of
technically brilliant high school students who cannot find the time to study but who
can,
nevertheless, spend many hours per week working on some technical problem. Imagine
your
scheme being subjected to the combined efforts of 100 (or more) Tom St Denis's (Tom, I
do
not mean to denigrate you by equating you with script kiddies; I used you as an example
because of your technical savvy and energy).
------------------------------
From: "Andreas Sewe" <[EMAIL PROTECTED]>
Subject: Re: IV for arfour
Date: Thu, 3 Aug 2000 15:02:29 +0200
"David A. Wagner" wrote:
> Andreas Sewe <[EMAIL PROTECTED]> wrote:
> > [...] you can still use your
> > RC4 key schedule for the generation of K, but having the possibility to
> > link it with the total range of IV permutations. [...]
> Yes, but what's the point? What do I gain by doing this?
> > Due to the integration of a real random IV, the range of possible
> > K_s is extend from 2^128 (max) to 256! in the above example.
> But my point is that K_s was already unlimited; there is no 128-bit
> limit. If you're not removing some limit on key size, what's the point?
Well, in theory K_s is limited to an 256 byte permutation, but using the RC4
key schedule, you have come up with K_e - 128 bit, 256 bit, ... up
to 2048 bit - being expanded (or crunched) to your 256 byte permutation,
K_i.
In case of expansion, you get, by using a real random permutation as IV, the
warranty, that all possible permutations for K_s can be used for
encryption.
In case of crunching, you get in fact nothing, but some kind of interface,
because linking two permutations, resulting in a third one, depends not on
the way your permutations were created - RC4 key schedule etc.
> > PS: Well, brute force on your 128 bit key still is an option.
> Worrying about brute force attacks on 128 bit keys seems pretty crazy
> to me, and I don't see the benefit of allowing log_2 256! = 1678 bit
> keylengths. But, as I said, RC4 already allows for such long keys,
> if for some reason you prefer them.
No, of course I'm not worried about brute-force against an 128 bit
space, but it is better by far then brute force against 256! permutations.
That's what the post scriptum was all about.
> Ok, I'm still lost. What's the motivation? Why do you want to consider
> these modifications to RC4? What problem are you trying to solve?
My motivation was to unchain the use of an IV from the original RC4 key
schedule, without forcing anyone to replace this schedule.
The problem is that generating permutations with the original key schedule
is
possibly secure, but using an IV, you have to find a way to link K and IV to
get K_s. This can be done, using the original key schedule - for example:
K_s = arcfour_key(K_e ^ IV); // XORing K and IV
or
K_s = arcfour_key(K_e + IV); // Concatenating them, both >= 1024 bit
But if you want an option for another key schedule, perhaps a real random
one for your IV, which does not have to be reproduceable, because any IV
is transmitted as plaintzext with your message, you have to find a way of
linking K and IV after you use arcfour_key().
K_s = (arcfour_key(K_e))[IV]; // K_s[n] = K_i[IV[n]];
I don't want to modify the RC4 cipher, I even don't want to modify the way
reproducable permuations can be created (by arcfour_key()), but I do want
a mechanism to link a key K and an IV, when they both are created in
a different way - I simply want an interface solving this problem.
Andreas Sewe
PS: Any confusion left?
------------------------------
Date: Thu, 03 Aug 2000 15:02:47 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Are You seen my two attachments ?
Leonid Nowikow wrote:
> Please say me : Are You seen my two attachments ?
Yep.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: OTP using BBS generator?
Date: 3 Aug 2000 13:17:05 GMT
Grant Anderson <[EMAIL PROTECTED]> wrote:
[Five times! Please don't post articles more than once. Pretty, pretty
please, with a cherry on top. Or I'll have to start complaining to
admins.]
> I know there has been much discussion about (supposed) OTP ciphers and
> how most of them generally don't fulfil the OTP requirements. What I
> don't understand is why the use of the blum-blum-shub generator as the
> pad isn't acceptable? I have read a great deal about the
> characteristics of the BBS generator and it *seems* secure as
> "random-number" generators go.
It *is* acceptable. The Blum-Goldwasser probabiliistic encryption
algorithm is based on this very same idea. I'll describe it below.
It's been proven to be semantically secure against polynomially-bounded
adversaries under the assumption of the difficulty of the quadratic
residuosity problem. This is essentially a polynomially-bounded version
of the security you get from a one-time pad.
> Assuming that each individual has a private key pair (two large
> primes) p and q and a public key n such that p x q = n, then the BBS
> generator creates bits by:
>
> x(i)=x^2 mod n for each i
>
> Now obviously you can't use the same pad twice, so you would need to
> do something like having a central repository (the keyserver for
> example) which remembers the last "i" value for each user. So when you
> want to encrypt for user A, you contact the keyserver and obtain their
> public key (n) and the initialisation value i and start generating
> from i+1....
>
> What is wrong with this solution?
Assume that I can see all the ciphertext messages. I keep polling the
key server and finding out where the counter is for my chosen victim.
When the counter changes, and a ciphertext arrives, I use the saved
counter to decrypt the message in exactly the same way that you
encrypted it. Note that there's no particular use for the modulus
factors in your system, and they're the only secrets in it.
A better idea would be to choose a *random* starting point: n is large,
so this isn't a great problem. Let's call the starting point x_0. Then
I encrypt with the least significant lg lg n bits of x_{i+1} = x_i^2 mod
n until the message is done. I'm left with x_N at the end of this. If
I append x_N to my ciphertext message, then the recipient, knowing N and
the factors p, q of n can recover x_1 (not x_0, because that might not
be a quadratic residue). Here's how:
* Firstly, note that if p = 3 (mod 4) then ((x^2)^{(p+1)/4})^2 = x^2
(mod n). (x^2 here is just some quadratic residue.) To see this,
just multiply it all out: p + 1 is multiple of 4, and p + 1 = 2 (mod
p - 1).
* Now compute y = x_N^{((p + 1)/4)^N mod (p - 1)} mod p and
z = x_N^{((q + 1)/4)^N mod (q - 1)} mod q. Combine y and z to find
a square root of x_1 mod n, using the Chinese Remainder Theorem.
*This* is Blum-Goldwasser probabilistic encryption.
It's vulnerable to a chosen ciphertext attack, by the way. You can
learn two square-roots for a value mod n, and hence factor the modulus.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: OTP using BBS generator?
Date: 3 Aug 2000 13:27:03 GMT
Mack <[EMAIL PROTECTED]> wrote:
> >The key thing for me is finding out if there is a good reason why
> >this isn't secure? There are proofs for BBS that prove it is as
> >difficult as factoring whereas almost all other schemes (RSA etc)
> >don't have a prove just a belief...
>
> The proofs that show BBS is as secure as factoring make a number of
> assumptions. In this case it is that the discrete logarithm problem
> is 'hard'. And that the quadratic residuosity problem is 'hard'. RSA
> has proofs that follow from similar assumptions.
Breaking the BBS is as hard as deciding quadratic residuosity. That's
certainly no harder than factoring, because you can use factoring to
decide quadratic residuosity, and indeed this is the only way we know
for doing this. The quadratic residuosity problem (QRP) is old and
well-known; however, we don't know that it's actually as dificult as
factoring.
By contrast, we know that breaking RSA is as difficult as solving the
RSA problem (RSAP). This isn't helpful -- it's just a restatement of
the same thing. We've no idea whether RSAP is actually difficult.
Again, the only way we know for solving the general RSAP is to factor.
On the other hand, RSAP is new.
> The BBS and RSA are very similar. BBS requires that the primes
> be of special form. RSA is a bit more liberal
The form for a Blum modulus isn't very special: the primes p and q must
each be congruent to 3 (mod 4); i.e., the bottom two bits of each should
be set. The other stuff with (p - 1)/2 being prime and so on isn't
particularly important unless you don't understand the security warranty
on the BBS generator.
> although for longest period they should probably be of the same form.
Can you justify this statement? I can't offhand see why an RSA modulus
would need to be a Blum integer for this.
> BBS is a bit more efficient than the RSA generator (one
> multiplication).
One squaring, in fact. Squaring is faster than multiplication.
-- [mdw]
------------------------------
Date: Thu, 03 Aug 2000 15:29:23 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: New block cipher for the contest
Manuel Pancorbo wrote:
> I don't see my post (7-30) about a new cipher. Hence, here it is again
Hmm I've seen it. I don't see other posts in this NG, however. Really,
sci.crypt behaves strange. Maybe one should open a new news-like
service in freenet or gnutella or such.
------------------------------
Subject: Re: OTP using BBS generator?
From: lordcow77 <[EMAIL PROTECTED]>
Date: Thu, 03 Aug 2000 07:01:49 -0700
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>BBS has been a recurring topic in this group. I have little
>knowledge in that but I have the impression that discussions
>about it never led to unanimously accepted results. You
>may try to look into old postings of this group.
>
Wrong. Practically everyone accepts that choosing the factors of
the modulus to be congruent to 3 mod 4 and picking a random
starting point are enough to ensure that the resulting BBS
sequence will be secure, based on the computational equivalence
of predicting BBS and deciding quadratic residuosity (and
therefore factoring). Terry Ritter is the only proponent of the
position that one must take elaborate steps to ensure that one
falls into a guaranteed long cycle on the basis of a
misunderstanding of the security proof given by Blum, Blum, and
Shub and a desire to assert that no cipher can be proven to be
secure under reasonable assumptions, such that he can promote
his own products that "stack" multiple patented algorithms
together.
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A non-linear extension of the Hill cipher
Date: Thu, 03 Aug 2000 16:20:35 +0200
John Savard wrote:
>
> If one makes one's matrix of the form
>
> 1 0 0 0 0
> * 1 0 0 0
> * * 1 0 0
> * * * 1 0
> * * * * 1
>
> where the 1's can be replaced by any number with a reciprocal, and the
> asterisks indicate any nonlinear function, not just squaring, and any
> rearrangement of rows and columns is allowed, one indeed has something
> invertible...but it is really a generalization of the Feistel round
> rather than the Hill cipher.
Perhaps we have some terminolgical disparities. Firstly, a Hill
matrix is generally full, not triangular. Secondly, a Feistel
cipher divides a block of input into two parts. In one round
a function of one half of the input together with a subkey is
used to transform (commonly xor) the other half. I don't yet
see how this fundamental characteristic of Feistel ciphers
can be expressed with a triangular matrix above. (What vector
or matrix does this triangular matrix operate on exactly?) On
the other hand, a Hill cipher and a Feistel cipher are both
transforms of input, i.e. have the most general form f(input),
as it should be for any cipher. If one writes out in full the
equations of the original Hill cipher and compare them with
the corresponding ones of the non-linear scheme I described,
one will see the close relationship between the two, while no
typical feature of the Feistel cipher is apparent, as far as
I can see at the moment.
Having mentioned above of the most general transform, I like
to point out that, if the 'whole' message file is divided into
a sequence of units (of any size, say word) v1, v2, ..... vn,
then the general iteration scheme that one could use for
crypto processing is of the form
vi' = f_i(v1, v2, ...., vi, ...., vn) (i= 1, 2, ...., n)
where f_i can be 'any' function subject to the condition that
it can always be uniquely solved for vi. The scheme I described
is certainly a rather special case of this. Note that f_i must
contain vi, while the other arguments need not all be present,
which means that a somewhat restricted f_i could be such that
it contains only a few number of the other elements, in
particular with these pseudo-randomly (dynamically) chosen from
the set {v1, ...., v_(i-1),v_(i+1), ...., vn}, i.e. without
there being a 'fixed' function. Employing such more general
iteration schemes could indeed be advantageous, especially in
view of the presence of 'variability' that is hard for the
opponent to deal with.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: OTP using BBS generator?
Date: Thu, 03 Aug 2000 14:15:13 GMT
On 3 Aug 2000 13:27:03 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Mark Wooding) wrote:
>Mack <[EMAIL PROTECTED]> wrote:
>
>> >The key thing for me is finding out if there is a good reason why
>> >this isn't secure? There are proofs for BBS that prove it is as
>> >difficult as factoring whereas almost all other schemes (RSA etc)
>> >don't have a prove just a belief...
>>
>> The proofs that show BBS is as secure as factoring make a number of
>> assumptions. In this case it is that the discrete logarithm problem
>> is 'hard'. And that the quadratic residuosity problem is 'hard'. RSA
>> has proofs that follow from similar assumptions.
>
>Breaking the BBS is as hard as deciding quadratic residuosity. That's
>certainly no harder than factoring, because you can use factoring to
>decide quadratic residuosity, and indeed this is the only way we know
>for doing this. The quadratic residuosity problem (QRP) is old and
>well-known; however, we don't know that it's actually as dificult as
>factoring.
But being "no harder than factoring" is meaningless when an approach
*allows* factoring.
The BB&S structure inherently includes both long and short cycles. If
an opponent encounters a short cycle and identifies a repetition, they
know the cycle length and can proceed to factor. Thus, use of a short
cycle can expose the system to factoring.
The BB&S paper shows how to construct a "special primes" system with
cycles of a known long length, and then to certify that one has
selected such a cycle, thus eliminating use of short cycles. But that
takes fairly arduous computation. See, for example:
http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect4.4
The alternative is to not use a "special primes" construction, and
simply not check for having selected a short cycle. The probability
of selecting a short cycle at random is extremely low, but not zero.
So where BB&S could argue that their scheme was provably secure, the
reduced scheme *might* not be secure, and that is a weakness.
I claim it is deceptive to call the reduced scheme BB&S. It is also
deceptive to claim that any system which we can make more secure by
our own action is absolutely secure. Here we have a case where the
security guarantee is factoring, but our own inaction can lead to
allowing exactly that factoring.
Any key-based ciphering whatsoever always has some probability of
opponents selecting the correct key at random, and so has inherent
weakness. We can't prevent that. But the use of a reduced X^2 mod N
structure has *additional* weakness which we *can* prevent. It is a
shame to say that is equivalent to the true BB&S design.
>By contrast, we know that breaking RSA is as difficult as solving the
>RSA problem (RSAP). This isn't helpful -- it's just a restatement of
>the same thing. We've no idea whether RSAP is actually difficult.
>Again, the only way we know for solving the general RSAP is to factor.
>On the other hand, RSAP is new.
>
>> The BBS and RSA are very similar. BBS requires that the primes
>> be of special form. RSA is a bit more liberal
>
>The form for a Blum modulus isn't very special: the primes p and q must
>each be congruent to 3 (mod 4); i.e., the bottom two bits of each should
>be set. The other stuff with (p - 1)/2 being prime and so on isn't
>particularly important unless you don't understand the security warranty
>on the BBS generator.
The security warranty from the real Blum, Blum & Shub paper is based
upon composites of large primes of a form which they call "special."
But now we have people using the part of BB&S they like, and throwing
out what they don't like. Do we really think the authors of the paper
did not see that possibility and decide against it? Please.
>> although for longest period they should probably be of the same form.
>
>Can you justify this statement? I can't offhand see why an RSA modulus
>would need to be a Blum integer for this.
I have seen various recommendations that RSA really should be using
special primes. Bob Eachus made one, as far as I remember.
>> BBS is a bit more efficient than the RSA generator (one
>> multiplication).
>
>One squaring, in fact. Squaring is faster than multiplication.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Martin 'SirDystic' Wolters" <[EMAIL PROTECTED]>
Subject: Kill my Cipher
Date: Wed, 2 Aug 2000 16:14:53 +0200
Hi
I wrote another Cipher, and I'd like
to hear, what you think about it.
It's a 16 round Feistel Cipher, which
uses 16 subkeys, generated like this:
int ky[0] = 0x00000000;
int kp[0] = 0x8F1BBCDC; (5^0.5)*(2^30)
for(i=1;i<17;i++) {
r=kp[i-1]&((1<<32)-1);
kp[i]=rot(ky[i-1],r);
ky[i]=kp[i]^kp[i-1];
}
where ky[0] is a 32 Bit User key and
rot(x,y) means a Left rotation of x by y
bits.
this is the f-function it uses:
int f(int in,int k)
{
int r,r2,o,o2;
in=~in;
r=k&31;
o=rot(in,r)^k;
r2=o&31;
o2=rot(o,r2)^k;
o2=~o2;
return o2;
}
the encryption routine is this:
for(i=0;i<16;i++) {
x1[i+1]=x2[i];
x2[i+1]=x1[i]^f(x2[i],ky[i+1]);
}
where x1[0] are the left 32 bits of
the 64bit Plaintext and x2[0] are the
rightmost 32bits of the Plaintext.
The decryption the same, the subkeys
are just used in reverse order.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Elliptic Curves encryption
Date: 3 Aug 2000 14:21:16 GMT
Terry Ritter <[EMAIL PROTECTED]> wrote:
>
> On Tue, 01 Aug 2000 13:26:12 -0500, in
> <[EMAIL PROTECTED]>, in sci.crypt Doug Kuhlman
> <[EMAIL PROTECTED]> wrote:
>
> >But knowing that "breaking" BBS (for example) is equivalent to
> >factoring is SOMEthing.
>
> No, it is not, and we just went through that a month ago.
Yes, we did, and you're still wrong now.
> When the supposed "BB&S" construction is used, there is a possibility
> -- admittedly very remote -- of having selected a short cycle. When
> that happens, the system can be broken due to repetition of the cycle,
> and that of course also allows the composite to be factored. Now,
> exactly *how* has it helped us to know that the failure allowed
> factoring?
Well, we know that finding cycles is at least as hard as factoring.
While we don't actually know how hard factoring is, it seems pretty
difficult, and has seemed difficult for hundreds of years. There are
two possibilities at this point:
* Finding cycles is harder than our best algorithm for factoring
integers. Then we don't need to care about cycles at all, because
factoring is a better attack anyway.
* Finding cycles *is* our best algorithm for factoring integers.
Well, we probably ought to care, but we still care just as much
about factoring, because it's (equivalent to) the best attack.
So either way, the thing to worry about is advances in factoring.
Cycles are really a bit of a red herring.
> So "breaking" BB&S means that we have found it to be weak to the given
> attack, and that -- my goodness! -- might not even overturn
> mathematics as we know it.
It would certainly be an interesting new factoring method.
> >I still would like you to present something to me as a fact.
>
> How about this: That's a stupid request.
Now prove that this is a fact. ;-)
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.math
Subject: Re: Sending Messages in Morse Code
Date: Thu, 03 Aug 2000 14:32:43 GMT
On Thu, 03 Aug 2000 02:52:35 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>American Morse was only partly like that: Some characters (e.g., C,
>O, R, Y, Z) had a longer spacing mid-character.
>
> "In Europe, an Austrian, Frederick Gerke, developed a variation
>of the Morse code that was adopted there. Many of the letters are the
>same in both codes. However, Gerke simplified the code by using only
>one space length and only two pulse lengths ('dits' and 'dahs').
>Gerke's code was easier to learn than Morse's, but it was somewhat
>slower. One interesting character is the letter 'O,' which is three
>dahs in Gerke's code. This is much longer than Morse's O, which is a
>pair of dits. Morse made O short because O is the fourth most common
>letter in English. However, in German, O is an uncommon letter,
>ranking only 16th, and for this reason was made long."
>Rutledge, D. 1999. The Electronics of Radio. Cambridge University
>Press. p. 308.
I had been looking for a reference that named whoever was responsible
for "Continental Morse", but could never find one! Thank you for
supplying this little tidbit of information...now, Morse joins
Uedemann and Baudot, as pioneering inventors, and Gerke joins
Gringmuth and Murray as those whose modifications bear the names of
the original inventors.
John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
