Cryptography-Digest Digest #416, Volume #11 Sat, 25 Mar 00 01:13:01 EST
Contents:
Re: OFB, CFB, ECB and CBC ([EMAIL PROTECTED])
Re: what is a 2048 bit cipher? ("Tom St Denis")
Re: OAP-L3: Answer me these? ("Tom St Denis")
Re: root mod a prime? ("Tom St Denis")
Re: ecc equation ("Tom St Denis")
Re: rc-5 plaintext guess. ("Tom St Denis")
Towards Efficient Stream Ciphers ("Tom St Denis")
Re: OFB, CFB, ECB and CBC (Jerry Coffin)
Re: OAP-L3: Answer me these? (Jerry Coffin)
Re: "THE DES, An Extensive Documentation and Evaluation" - from Aegean ("Douglas A.
Gwyn")
Re: what is a 2048 bit cipher? ("Douglas A. Gwyn")
Re: Pseudo random sequences test ("Douglas A. Gwyn")
Re: OAP-L3: Answer me these? (Jerry Coffin)
Re: Gray Code like ("Douglas A. Gwyn")
Re: An RC5-like cipher (csybrandy)
Re: Secret Key (En|De)cryption functions (David Formosa aka ? the Platypus)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: OFB, CFB, ECB and CBC
Date: 25 Mar 2000 03:00:06 GMT
In a previous article, Jerry Coffin <[EMAIL PROTECTED]> writes:
>In article <8bfdr8$6im$[EMAIL PROTECTED]>,
[--cut--]
>If you know the key, nothing much else matters at all...
OK. Forgive me. I wrote that in a hurry. Why does everyone insist that I meant
that the _attacker_ knew the key? Of course I did not mean that. I meant
"suppose that the key if given", which, according to my experience, is a
quite normal way to state conjectures in mathematical reasoning.
>> Using a stronger cipher would probably often be a better way to increase
>> security than to go from ECB mode to either CBC or CFB mode.
>
>Rather the contrary: simply a "stronger" cipher won't necessarily
>provide ANY extra security against some types of attacks.
No, not necessarily. That's why I used the words "probably often".
>And what exact attacks work against OTPs?
If the attacker knows some plain text P, then the attacker will be able to
exchange that plain text for a forgery P', by the operation C' = C xor P xor
P', and replace C by C' in the stream.
[---]
>In any case, the difference between third and last is pretty
>meaningless in any case: [---]
Is it? It seems perfectly rational to rank the modes according to the security
they will give in a particular environment, but choose a mode only after also
considering other factors, e.g. efficiency and practicality.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: what is a 2048 bit cipher?
Date: Sat, 25 Mar 2000 03:21:23 GMT
Normally attacks don't depend on how big the key is, but how it's used.
Take the analysis of SAFER+ for example. It's possible to make a better key
schedule and have the 256 bit key space, but the original key schedule
didn't use the key bits properly.
However, the attack on 256-bit SAFER+ does not work on the 128 bit (key
size) SAFER+ since it requires more work. So your line of thinking is
flawed.
Tom
Jerry Coffin <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <MaNC4.67100$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
>
> [ ... ]
>
> > > Indeed. Pumping up your keyspace is very likely to increase the
> > > difficulties experienced by analysts. Of course, even 2048 bit
> > > cyphers can be broken...
> >
> > You are so wrong. Making the keyspace large is only effective if your
> > algorithm is secure. So even a cipher with a 80 bit key would be secure
by
> > todays computer standards [maybe not 20 years from now..., but for now].
>
> Keep in mind that crytanalysis _typically_ results in a reduction of
> the work by some _factor_ of what it takes to exhaust the key-space.
> Stated in a different way, it reduces the effective key size by some
> number of bits.
>
> If you start with an 80-bit key, you have to be essentially
> _absolutely_ certain (which you can't be) that nobody can find an
> effective attack that'll reduce the strength at all, even if you only
> need relatively short-term security.
>
> If, OTOH, you start with a larger key, somebody can find a fairly
> significant attack without being able to compromise your security.
> Just for example, if you start with a 256-bit key, even if they can
> reduce the effective key size to 128 bits, they're nowhere close to a
> practical attack. If they reduced an 80-bit key by the same factor,
> they'd only need to search a 40-bit keyspace which is quite feasible.
>
> At the same time, it should be noted that if you're going to try to
> be conservative by using a large key, you also (generally) need to be
> relatively conservative in other areas as well to stand a good chance
> of making any real use of the key -- a larger key normally requires
> either greater complexity in each round or else a larger number of
> rounds to get full diffusion.
>
> With that said, there's really no question that your basic idea is
> still correct: 100 bits or so is enough for security for quite a
> while unless there's a major break against the cipher, or a major
> breakthrough in computing technology. Of course it's handy for the
> key size to be a power of 2, so 128-bit keys are fairly common.
> There's honestly little practical purpose for keys a lot larger than
> that -- I realize AES requires support for a 256-bit key, and to
> _some_ extent I can sympathize with NIST requiring: the small key
> used with DES has been a sore point for years, and they're probably
> just (over-)reacting to that criticism. The other point is that it's
> not a _lot_ of extra work to support a larger key, so they might as
> well.
>
> Despite this, it's still basically overkill, and the dramatically
> larger keys some people use are basically pointless as well.
>
> --
> Later,
> Jerry.
>
> The universe is a figment of its own imagination.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Date: Sat, 25 Mar 2000 03:22:43 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : Tim Tyler <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> :> In sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> :> : A keyspace of more then say 160 bits is a waste of resources....
> :>
> :> So, the One-Time-Pad is dead, then? ;-)
>
> : Yes it is.
>
> I suppose its use in quantum cryprography protocols is just a theoretical
> exercise as well. After all, nobody would bother using a key the size of
> the message when all you ever really need is 128 bits or so ;-)
>
> To be fair, I *also* think the OTP is only rarely useful - but this is
> because of its use of XOR and its lack of diffusion - rather than any
> concern about the size of its keyspace.
Your line of thinking is flawed. An OTP is the PERFECT cipher. It doesn't
need diffusion. And for the time being 128 bit keyspace is more then
enough, and 256 bits is excessive.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: root mod a prime?
Date: Sat, 25 Mar 2000 03:24:50 GMT
The problem is that I am adding this to my crypto library, and want to be
able to make new curves as the user sees fit.
Tom
lordcow77 <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <6eQC4.67826
> $[EMAIL PROTECTED]>, "Tom St Denis"
> <[EMAIL PROTECTED]> wrote:
> >That's the thing I don't know the order of the curve, because
> it's made at
> >random.
> >
> >Tom
> >
>
> Grrr. Read the postings that you reply to once in a while. Don't
> create an eliptic curve at random for every ECC key generation
> operation that you will perform. Pick a curve whose number of
> points have already been determined by others and pick your
> specific points on that curve. It's either really simple (cut
> and paste the precomputed domain parameters into your app) or
> really difficult (generate a curve, count the number of points
> again, determine if #E is prime or has a large prime factor,
> increment B, repeat until such a curve is found).
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network
*
> The fastest and easiest way to search and participate in Usenet - Free!
>
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: ecc equation
Date: Sat, 25 Mar 2000 03:27:20 GMT
lordcow77 <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >Well that's just the thing I can't find any descriptions of any
> >of the algorithms online. Even if I don't understand the
> >algorithm I may be able to implement it.
>
> Firstly, I do not believe that you will be able to implement
> even Schoof's original algorithm with the level of mathematics
> knowledge that you currently seem to have. There is some heavy
> algorithm wizardry to make the algorithm run at even a
> reasonable speed and the math used is essentially on the cutting
> edge of research in that field. Secondly, even if you were able
> to produce a working implementation, it would not really be
> productive as others have already done the same. Thirdly, you
> will gain practically nothing by such an exercise after spending
> many hours that could be far more productively spent doing other
> activities.
No offense, but f@@@ you. Who are you to say I am a know-nothing? In my
current library I have implemented RSA, several symmetric ciphers, a
secure-PRNG, etc... So don't say I don't know what I am doing.
Second who are you to say what I should or should not be using my time for.
Even if I don't get the math right away I would still want to see it. You
know there was a time when I didn't understand RSA or even the simplest
large number math...
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: rc-5 plaintext guess.
Date: Sat, 25 Mar 2000 03:28:43 GMT
lordcow77 <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Regardless of how stupid the original poster's statement was, it
> is not very pleasant to tell him to "go back to school junior"
> You imply without evidence certain characteristics that he may
> or may not possess. People on this newsgroup have been very
> tolerant of the mistakes and inaccurate statements that you have
> made in the past and sometimes still make as you are learning
> about cryptography. Please do other the same courtesy that was
> provided to you.
>
> By the way, in standard English syntax, sentences begin with
> capital letters.
Typically we don't control people either. Or tell them they are stupid and
they should find something else todo.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Towards Efficient Stream Ciphers
Date: Sat, 25 Mar 2000 04:18:17 GMT
On my page http://24.42.86.123 I describe a method to use a simple fibonacci
generator to output a secure PRNG stream. It can be modeled as small as
your PRNG so if you choose the classic (55, 24) generator the entire
secure-PRNG requires only 55 bytes of memory. I can think of many
applications for ciphers that require so little space.
Another nice benefit is the period can easily be approximated since it's
based on the well understood theory of fibonacci generators.
While the current proposed model of usage [i.e with 8-bit words in the
array] it's rather slow (about 110 bytes/msec on my K6-2 400) it's very
compact code/ram wise and easy to implement.
If anyone has any comments or thoughts on it, just post.
Tom
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: OFB, CFB, ECB and CBC
Date: Fri, 24 Mar 2000 22:03:08 -0700
In article <8bha3m$q8m$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> >Rather the contrary: simply a "stronger" cipher won't necessarily
> >provide ANY extra security against some types of attacks.
>
> No, not necessarily. That's why I used the words "probably often".
The contrary is still basically true: there may be something _else_
about the stronger cipher that happens to also provide some help
against these kinds of attacks, but the strength of the cipher alone
doesn't do any good at all.
For example, if a particular input block gets encrypted with a
relatively weak cipher, and you learn to recognize the output block
created from it as being associated with some particular subject,
changing to a stronger cipher doesn't really make any difference at
all.
It could make a difference if (for example) the stronger cipher also
happened to use a larger block size so you ended up needing a longer
block before the output was recognizable. IOW, without specifying
the exact ciphers under discussion, it's impossible to say that
there's NO effect, but the strength of the cipher, by when there is,
the strength of the cipher is more or less coincidental and it's
something else that's helping things out.
> >And what exact attacks work against OTPs?
>
> If the attacker knows some plain text P, then the attacker will be able to
> exchange that plain text for a forgery P', by the operation C' = C xor P xor
> P', and replace C by C' in the stream.
As I pointed out, you're assuming that an OTP uses an XOR to combine
the key with the plaintext. That's a simple model that's easily
proven effective against some kinds of attacks, but it's NOT the only
way an OTP can work.
IOW, the concepts involved are entirely orthogonal: an OTP can be a
Vernam cipher, or essentially any other type. A Vernam cipher can be
an OTP, or can use almost any number of other ways of generating a
stream to be combined with the plain text. The attack you're
discussing applies to Vernam ciphers, NOT to OTPs.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Date: Fri, 24 Mar 2000 22:07:10 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> To be fair, I *also* think the OTP is only rarely useful - but this is
> because of its use of XOR and its lack of diffusion - rather than any
> concern about the size of its keyspace.
I think OTPs are rarely useful because of key distribution problems.
Your assumption that an OTP uses an XOR and/or lacks diffusion is
simply incorrect: while it's the most commonly discussed method of
implementing an OTP, it's NOT a characteristic of OTPs in general.
I believe it's Doug Gwyn who's _repeatedly_ pointed out that a Vernam
cipher is not the only way of implementing an OTP, and in fact not
the way that most real OTPs work at all. It simply happens to be a
relatively simple way of demonstrating the way an OTP can work.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: "THE DES, An Extensive Documentation and Evaluation" - from Aegean
Date: Sat, 25 Mar 2000 05:12:11 GMT
Jack Diamond wrote:
> DES is filled with trap doors, so you might learn as much by doing
> simple distribution analysis and finding them.
What "trap doors"?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: what is a 2048 bit cipher?
Date: Sat, 25 Mar 2000 05:17:31 GMT
Tom St Denis wrote:
> You are so wrong. Making the keyspace large is only effective if
> your algorithm is secure. So even a cipher with a 80 bit key would
> be secure by todays computer standards [maybe not 20 years from now...
You apparently contradict yourself. Perhaps what you mean was:
A very long key does not in itself guarantee security, although
a sufficiently short key (much less than 80 bits) does guarantee
insecurity.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Pseudo random sequences test
Date: Sat, 25 Mar 2000 05:25:19 GMT
[EMAIL PROTECTED] wrote:
> What could be the equivalent of Maurer's Universal Test for
> pseudorandom sequences ?
What do you mean by "equivalent of"? Can't Maurer's test (or
some improvement thereof) be applied to pseudo-random sequences?
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Date: Fri, 24 Mar 2000 22:29:36 -0700
In article <7iWC4.69406$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> Your line of thinking is flawed. An OTP is the PERFECT cipher. It doesn't
> need diffusion. And for the time being 128 bit keyspace is more then
> enough, and 256 bits is excessive.
His line of thinking was and is correct, as long as you restrict OTPs
to the sort of implementation of which he was thinking. Despite
being entirely immune to a cipher-text only attack, a one-time pad is
a LONG ways from perfect in general. In particular, even if you
don't know the exact plaintext, if you know the _format_ of the
plaintext, it's subject to bit-flipping attacks.
Just for example, here in the US some people were recently allowed to
cast ballots for primary elections over the Internet. Though I doubt
it's true, for the moment assume that ensure security the votes were
encrypted using a OTP, implemented in the style usually discussed (a
Vernam cipher).
For example we'll assume I'm opposed to the Democratic party and I'm
willing to be dishonest to try to make them lose. In the democratic
party, there were basically two candidates in the primary elections:
Bill Bradley and Al Gore. I want to ensure that the LESS popular of
these two gets elected, so that in the final election, more Democrats
are likely to vote FOR whoever is running against the unpopular
Democratic candidate.
Now, consider the situation for the moment: I don't particularly care
which of these candidates anybody in particular has voted for. I'm
not trying to find out how the election will go before it's
officially announced. And that's just as well, because their use of
a one-time pad will quite thoroughly prevent me from doing that.
Despite this, if a particular person's vote is represented (for
example) as a single bit, with a 0 representing a vote for one
candidate, and a 1 a vote for the other, I can easily switch
everybody's votes: I simply toggle the bit from whatever it presently
is, to the other possible value. Suddenly everybody's vote is
reversed, and the election goes to the least popular candidate
instead of the most popular. When the final election comes around,
the opposing party's candidate is running against somebody nearly
nobody would intentionally vote for, and the election is a landslide
because the legitimate opposition was eliminated before anybody could
vote for him at all.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Gray Code like
Date: Sat, 25 Mar 2000 05:37:58 GMT
Tim Tyler wrote:
> Note that (apart from the leading zeros), this pattern mirrors the
> internal state of a maximal-period LFSR.
> Consequently you could build such sequences of any given length by
> using the tap sequence for a maximal-period LFSR, starting from the
> "...001" state and prepending the "...000" state to the list.
I think you're assuming that *any* maximal-length sequence can be
generated by a suitably-tapped LFSR. Is that actually a theorem?
------------------------------
From: csybrandy <[EMAIL PROTECTED]>
Subject: Re: An RC5-like cipher
Date: Fri, 24 Mar 2000 11:40:28 -0500
Reply-To: [EMAIL PROTECTED]
Tom St Denis wrote:
>
> Samuel Paik <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Tom St Denis wrote:
> > > > for (i = 0; i <= 2*R+1; i++)
> > > > {
> > > > B = B + S[i];
> > > > A = A ^ B;
> > > > A = ROTL(A, B);
> > > > SWAP(A, B);
> > > > }
> > >
> > > I don't like this. the modification of A and B is entirely linear. I
> can
> > > for example work A backwards one round by doing
> >
> > Well, it isn't linear, it just is completely independent of any key bits
> > and completely determined by known to the attacker data.
>
> Um
>
> B = B + S[i]
> A = A ^ B
>
> are BOTH linear. And after around I can rever the rotation, so ...
>
> Tom
A possible modification could be this:
A = ROTL((A ^ B), B);
B = B + S[i];
Therefore, if you can't guess S[i], you've hidden the value of B that
was used on A.
csybrandy
------------------------------
From: [EMAIL PROTECTED] (David Formosa aka ? the Platypus)
Crossposted-To: comp.lang.perl.moderated
Subject: Re: Secret Key (En|De)cryption functions
Date: 25 Mar 2000 05:11:01 GMT
Reply-To: dformosa@[202.7.69.25]
On Wed, 22 Mar 2000 21:07:56 +0000, David L. Nicol
<[EMAIL PROTECTED]> wrote:
[...]
>Stick the following in a file called "CryptLib.pl" and pull
>it into your program with C<require "CryptLib.pl"> for secret
>transmission and storage of arbitrary perl scalars.
>
>Uncomment print statements to see the algo in action. I tested it
>with this command line invocation:
Its also increbbly week. All I need to know is the plantext and I can
work out what the scret is. And since you are takeing orders I can
even make use of a given plantext attack. All I have to do is give a
plaintext containing all zeros and the key pops right out.
[...]
>The above code is copyright 1979, 2000 David Nicol, and is hereby
>released for general use.
Given its a Ceaser cypher with a plain text feed back I don't think
you will have to worry about copyright violations
--
Please excuse my spelling as I suffer from agraphia. See
http://www.zeta.org.au/~dformosa/Spelling.html to find out more.
Interested in drawing platypie for money? Email me.
------------------------------
** 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
******************************
