Cryptography-Digest Digest #415, Volume #11 Fri, 24 Mar 00 22:13:01 EST
Contents:
Re: Card shuffling (Mok-Kong Shen)
Re: NIST publishes AES3 papers ("Joseph Ashwood")
Re: rc-5 plaintext guess. ("Richard Lee King Jr.")
Re: Factoring Large Numbers - I think I figured it out! (Jerry Coffin)
Re: root mod a prime? (David Hopwood)
http://www.cryptomat.com ("Borys Pawliw Newsgroups")
Re: root mod a prime? (lordcow77)
Re: rc-5 plaintext guess. (lordcow77)
Re: OFB, CFB, ECB and CBC ([EMAIL PROTECTED])
Re: Re-seeding PRNG's in central key distribution systems (Bryan Olson)
Re: ecc equation (lordcow77)
Re: OAP-L3: Answer me these? (Tim Tyler)
Re: OFB, CFB, ECB and CBC ([EMAIL PROTECTED])
Re: Hashes! (newbie question) (Jerry Coffin)
Re: OFB, CFB, ECB and CBC (Jerry Coffin)
Re: Gray Code like (Tim Tyler)
Re: Hashes! (newbie question) (Jerry Coffin)
Re: rc-5 plaintext guess. ("Richard Lee King Jr.")
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Card shuffling
Date: Sat, 25 Mar 2000 00:26:48 +0100
wtshaw wrote:
>
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
> > A ideal random device will produce every permutation with equal
> > chance, but it doesn't follow from this that each permutation has
> > equal 'ordered-ness' which is a (independent) quantity that we could
> > yet define. (The six surfaces of a perfect dice have equal chance
> > of being on the top, but it doesn't follow that they carry the
> > same number of dots.)
>
> The most important attribute of cards or dice is that they are impartial,
> they don't care. If dice are loaded, or cards are shaved, then they have
> a proclivity to be biased.
Cards are more complicated. Since cards are shuffled by hands,
the human factor may be quite essential. However, whatever the
chances of the different permutations, biased or not, there
is a sense to say that some permutations have higher disorder
than the others, since the concept of disorder is independent
of the said chance.
> > A reverse order is not the same as the original
> > but it has some amount of order in it, right? If someone arbitrarily
> > shuffles the deck, then one normally gets more disorder. So in some
> > global sense it should be possible to compare two occurences of
> > 'disorder' even though that comparison might not be precise enough
> > and subject to an fair amount of uncertainty.
>
> All shuffles are honest if the person does not know how to manipulate the
> deck' therefore, all such shuffles of neutral decks are equal. If somone
> knows a bit too much about how to manage the cards, he can not usually
> perform an honest shuffle at all.
An honest person may yet shuffle poorly, if he is inexperienced
in the task or perhaps handicaped due to injury, for example.
M. K. Shen
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES3 papers
Date: Fri, 24 Mar 2000 15:27:14 -0000
"David A. Wagner" <[EMAIL PROTECTED]> wrote
in message
news:8bfv9n$2jt$[EMAIL PROTECTED]...
> In article <#$CMhOVl$GA.154@cpmsnbbsa02>,
> Joseph Ashwood <[EMAIL PROTECTED]> wrote:
> > Actually most implementations [of 3DES] only use 2 keys,
because of
> > the meet in the middle attack.
>
> That's just plain not true.
>
> Most implementations of 3DES that I've seen use 3 keys.
I think we have different experiences to bring, it's
probably worth discussing the merits of each.
>
> And anyway, if you are worried about MITM attacks, using
> 2 keys is a silly response -- it doesn't add any
protection
> against MITM attacks, and is definitely weaker against
> some attacks.
At first it seemed silly to me also, but since EDE form has
started to take over as the standard, the meet in the middle
attack would require the same amount of memory (within
approximation), and using a 3rd key for the last encryption
would add no (read trivial) security, the natural result
from the standpoint of many was to use only 2 keys.
In my mind it would have been more secure to use 3 keys
simply because of the fact that reusing round keys tends to
weaken the overall system, and in this case DES is being
treated as a round function. However management sees things
differently, and they really are the ones who rule
workforce, not you or I.
It has been mentioned that in IPsec 3 keys is necessary,
since this spec is growing in popularity, the tide may be
changing without me having yet seen it. In the mean time I
guess I have to play a kind of devil's advocate (look up the
reference if you are offended), and argue the merits of
2-key 3DES, just to observe the outcome.
Joe
------------------------------
From: "Richard Lee King Jr." <[EMAIL PROTECTED]>
Subject: Re: rc-5 plaintext guess.
Date: Sat, 25 Mar 2000 00:05:17 GMT
ok then, how about:
it sounds better....
1 "The "
2 "unkn"
3 "own "
4 "mess"
5 "age "
6 "is: "
7 "This"
8 "is R"
9 "SA l"
10 "abs'"
11 " RC5"
12 " pub"
13 "lic "
14 "key "
15 "cont"
16 "est."
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:_fQC4.67857$[EMAIL PROTECTED]...
> What the heck is this?
>
> Go back to school junior.
>
> Tom
>
> Richard Lee King Jr. <[EMAIL PROTECTED]> wrote in message
> news:PZPC4.1262$[EMAIL PROTECTED]...
> > here is my guess for the rc5-32/12/8 contest.
> >
> > 1 "The "
> > 2 "unkn"
> >
> > 3 "own "
> > 4 "mess"
> >
> > 5 "age "
> > 6 "is: "
> >
> > 7 "You "
> > 8 "win "
> >
> > 9 "RSA "
> > 10 "labs"
> >
> > 11 " RC5"
> > 12 " pub"
> >
> > 13 "lic "
> > 14 "key "
> >
> > 15 "cont"
> > 16 "est."
> >
> >
> >
> >
> >
>
>
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Factoring Large Numbers - I think I figured it out!
Date: Fri, 24 Mar 2000 17:38:54 -0700
In article <ZoQC4.67991$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> > Simply being smaller doesn't necessarily mean a number is easier to
> > factor.
>
> Actually the NFS will factor numbers regardless of composition in about the
> same estimated time/space. So size does matter.
Please reread what I said and take particular note of the word
"necessarily" in what I said.
I'm well aware that the NFS is basically unaffected by the number of
factors of a number. That doesn't necessarily mean much though. For
example, assume you have a 1000 digit number and you want to factor
it. You can quickly compute the requirements for an NFS and give up
before you start because there's simply no way you can finish.
Despite this, it may be possible to factor the number anyway -- just
for example, if it has a lot of small factors, Pollard's Rho may
factor it in a very reasonable amount of time. In some cases, the
number may be simple enough that you can even factor it by hand --
the most extreme example would be a 1 followed by 999 (or even more)
zeros. Factoring that is quite trivial even though there's
absolutely NO way to do it with an NFS. I suppose that approaches
the "reductio ad absurdium" level, but the fact remains: the
difficulty of factoring a number is NOT related _strictly_ to its
size, but on other factors as well (no pun intended).
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
Date: Fri, 24 Mar 2000 02:30:59 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: root mod a prime?
=====BEGIN PGP SIGNED MESSAGE=====
Mike Rosing wrote:
> Good crypto curves have order r*p where r is small and p is a big prime.
> Pick a point at random and multiply by r. If the result is not the
> point at infinity, then the result has order p.
OK so far.
> You can check that a point has a given order by multiplying it by the
> order you expect it to have and see if you get the point at infinity.
Careful: if kP is the point at infinity then the order of P divides k,
but it is not necessarily equal to k.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBONrTOzkCAxeYt5gVAQFGkgf+LPEw+QebewcvTUnoiaRi9nDp020Y+BCh
PTeGGpzVeKhYkObOHhgR9TGVJ66D2HPpopEsWx3k04akoT9HwW9iyViLOowvdXA+
mc/2SSfpz9tS8FOkk9rOLZSaMiQ/YUMRKPeFLTUGCcdKgmypb2gI6LQZM2bSOfX+
aNMlInJ6XcCV48qYENxoq3tFRyq0K5QaMSmh3/Tvjt8SGa6DHfPoO06+VDk/yZ8i
s0YFpo/V9jpmI4UdVfZ/ewhYr4g290BVXi+5uamISqBWVnYAI2USpuGKPqva2pAD
2Z9zhtAn6gCj4wjn47Wwuwc39eiRbZjBL/dYPZ7MlijUlz9OpLfLgw==
=A8mI
=====END PGP SIGNATURE=====
------------------------------
From: "Borys Pawliw Newsgroups" <[EMAIL PROTECTED]>
Subject: http://www.cryptomat.com
Date: Sat, 25 Mar 2000 11:51:49 +1100
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am presently investigating the site http://www.cryptomat.com, the
individual(s) behind which claim to be able to decipher ciphertext
that was encrypted with supposedly secure, publicly available strong
protocols (assume PGP et al). They even offer a service where you
send then ciphertext and they will decrypt a portion of it as a
demonstration of their abilities. I tried this service, but as of yet
have not received any reply (11 days as of 25th March).
My initial assessment is leaning towards this site being a scam.
There are spelling errors (always a worry) which I pointed out to
them, but they only corrected a portion of them. Their overall claim
seems to defy presently known limits of mathematics.
Nevertheless, it seems a fair amount of trouble to go through for a
scam with little discernable reward, other than perhaps a list of
email addresses of individuals interested in cryptanalysis. They are
very much into anonymity - but perhaps that was not enough to prevent
some large gentlemen in black suits driving Chevy Suburbans with
black out windows with Maryland plates taking care of them?
I would appreciate any feedback from anyone who has any knowledge of
this site or the individuals behind it.
Best wishes.
Borys Pawliw
- -----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use
<http://www.pgp.com>
iQA/AwUBONuA06fc3zNYYmpUEQLX8wCZATRe8zi/nY6K8DAPyzhzflv9I24An0uI
DRDiFvhLDI55mvNIo7p+Bph9
=jPl7
- -----END PGP SIGNATURE-----
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
iQA/AwUBONuBBafc3zNYYmpUEQIkegCggfUXJeBPdXaGg0F4BYp752KfWIoAoPjc
wo5PIcCbLMy3qDUaNDmkc+Ov
=xBvH
=====END PGP SIGNATURE=====
------------------------------
Subject: Re: root mod a prime?
From: lordcow77 <[EMAIL PROTECTED]>
Date: Fri, 24 Mar 2000 17:49:05 -0800
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!
------------------------------
Subject: Re: rc-5 plaintext guess.
From: lordcow77 <[EMAIL PROTECTED]>
Date: Fri, 24 Mar 2000 17:53:02 -0800
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.
* 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: [EMAIL PROTECTED]
Subject: Re: OFB, CFB, ECB and CBC
Date: 25 Mar 2000 01:58:42 GMT
In a previous article, "Scott Fluhrer" <[EMAIL PROTECTED]> writes:
[--cut--]
>Actually, you're misunderstanding the problem with ECB that CBC (and CFB)
>are designed to overcome.
[--cut--]
This is really off topic, but nevertheless important.
Don't make assertions about what other people understand or don't understand.
You don't know that. All you know is what they in fact wrote. Making such
assertions is more likely to make people upset than to make them understand.
The rest that you wrote is of course true.
----- 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: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Re-seeding PRNG's in central key distribution systems
Date: Sat, 25 Mar 2000 01:45:23 GMT
[EMAIL PROTECTED] wrote:
> The solution need not involve reseeding the PRNG. Simply
> don't use an insecure one that allows prediction of all
> subsequent states from a tiny quantity of its output.
>
> There are *plenty* of RNGs that fit this bill in the literature.
Correct, and the requirements on PRNGs for key generation
are even stronger. Specifically, even given the state
of the PRNG, one should not be able to determine previous
outputs. This is not usually a requirement on stream-cipher
PRNGs, and thus a strong stream cipher is not automatically
good for key generation. One should not, for example, use
RC4.
The currently most popular PRNG for key generation is
adapted from the one described in FIPS 186, by omitting the
"mod q" of the output.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: ecc equation
From: lordcow77 <[EMAIL PROTECTED]>
Date: Fri, 24 Mar 2000 18:00:44 -0800
>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.
* 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: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 25 Mar 2000 01:43:11 GMT
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.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
The cat that ate the ball of wool just had mittens.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: OFB, CFB, ECB and CBC
Date: 25 Mar 2000 02:18:02 GMT
In a previous article, Eric Lee Green <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] wrote:
>> You may make CFB and CBC modes sound better than they are. In fact, if you
>> know then key and cipher (= E_k) and only two adjactent plain text blocks
>> p(n-1) and pn, then you know ahead of time what the cipher block cn will
be.
>
>The point of CBC mode is to hide patterns and fight replay attacks (since an
>injected block probably won't decrypt to the text that the attacker thinks,
a
>situation that can be caught with CRC's or whatever). If the attacker knows
>the key and cipher then you're screwed anyhow.
Just to straighten this out. I was (implicitly perhaps) referring to how the
complexity of an attack on the key depended on the cipher mode. I claimed
that the difference was not that big. The conjuncture "if you know the key
and cipher" should not be interpreted as I assumed that the attacker already
knows the key and cipher. I was discussing the amount of data the attacker
would need to be theoretically able to derive the key.
>> Hence, the complexity is increased compared to ECB mode, but not that
much.
>> 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.
>
>You are correct about CFB mode, which actually reduces security because it
>suffers from the same flaws as a one-time pad -- two messages encrypted with
>the same keystream (i.e. combination of "salt" and key) can be attacked.
It seems to me that you use the term "CFB" as I use "OFB". Cipher feedback
mode means (to me) that the previous cipher block is moved to the feedback
pipe and encrypted before xor:ed with the plain text block.
OFB mode means that the previous iterated encryption of the IV is moved to the
feedback pipe and encrypted before xor:ed with the plain text block. It is
OFB mode which suffers from the same flaws as the one-time pad (and I did in
fact point that out in my first post).
----- 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: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Hashes! (newbie question)
Date: Fri, 24 Mar 2000 19:28:02 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> Thinking a bit more clearly now, though, the situation isn't quite as
> grim as I might have made it appear. I think what you should have said,
> rather than making excuses about other uses of hashes, is something
> like:
Why do you call pointing out that birthday attacks don't work in most
situations "excuses"? If you buy a car to get groceries, do you
consider that merely an "excuse" for not buying a tractor-trailer
with 200 ton cargo capacity?
> If an adversary wants to forge your signature on a document by fiddling
> with the hash (for some nefarious reason), he has to find a collision
> /now/, i.e., before you sign the collided hash. After you've signed,
> he'd has to find a second preimage, which (as you point out) is much
> harder. So we can safely stop using the hash when its collision
> resistance starts to look insufficient, and old signatures will still
> remain good for a while afterwards.
A _long_ while afterwards -- we're to the point that we can _barely_
contemplate working on 80-bit size problems. Moore's Law/observation
doesn't have to work for a lot longer to say that special hardware
could feasibly be built to attack this size of problem.
OTOH, we haven't even a clue of what it'll take to attack 160-bit
sized problems. To even come close, we have to assume Moore's
law/observation will hold out for another 80 to 90 years before we
can begin to contemplate such a search. Unfortunately, we can
already foresee _huge_ problems with that happening -- I'm not ready
to categorically state that it won't, but it won't surprise me a bit
if it doesn't either.
In any case, the simple fact is that this applies almost strictly to
the case of signing hashes of documents. The day may come when
electronic signatures are typically used on long-term agreements and
such, but the fact is that right now they're typically restricted to
things that are of a relatively ephemeral nature anyway, so being
able to forge an electronic signature nearly a century after the fact
seems unlikely to be useful very often.
> So, yes, my gloomy picture from my last message was over-pessimistic.
> However, I still think that security expectations for collision
> resistant functions are disproportionately low, and I'd very much like
> to see strong hashes with larger outputs, to bring them back in line.
I think you have a slightly skewed version of things. Think about the
history of things. Long ago, DES was devised with its 56-bit key.
For years, this was "ahead" by default, because there WAS no
offiically sanctioned hash/signature algorithm.
Then, along came DSA/SHA-1, with a 160-bit hash. DES was still the
only officially sanctioned form of encryption, so for a while,
hashing had a larger effective key space to deal with.
Now, they're _working_ on AES, but haven't finished it yet. The
currently reccommended form of encryption in FIPS 46-3 is 3DES, with
an effective key size of 112 bits. DSA is still at 160 bits, so
depending on the attack you're defending against, it's either a bit
larger or a bit smaller.
When AES is approved, it will clearly be ahead, at least in theory.
Personally, I think at least for quite a while, most use of AES will
be with 128-bit keys, not 256-bit keys. Assuming that's so, it will
retain essentially the current situation: the official hashing will
be a bit stronger against some attacks and a bit weaker against
others.
When/if there's good reason to believe an attack on an 80-bit space
will become feasible reasonably soon, it seems fairly easy to imagine
combining hashes, such as using both SHA-1 and RIPEM to produce a
160-bit overall result that you actually sign.
At some point, much as with the current situation with AES, people
will likely have some concern that this sort of stop-gap really isn't
particularly wonderful, and they'll probably decide a nice round size
for the next standard hash is 512 bits. It won't take a huge amount
to define a hash producing that size of output, and for a little bit,
the balance will be in favor of hashing being a bit more secure for a
while.
> In a vaguely similar vein, has anyone any actual results against
> RIPEMD-320 (i.e., the RIPEMD-160 variant which doesn't split recombine
> the chaining variables between the two parallel streams of rounds)? I'm
> aware that the authors don't suggest that this variant offers any
> security advantages over RIPEMD-160 itself, and I'm not actually
> intending to use it, but I'd be interested to know nonetheless.
I don't know of any. If I wanted a 320-bit hash, I'd combine it with
SHA-1 instead, but that's just me. Of course, this is a slower
route, but I don't see all that many situations in which it really
matters.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: OFB, CFB, ECB and CBC
Date: Fri, 24 Mar 2000 19:28:00 -0700
In article <8bfdr8$6im$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> You may make CFB and CBC modes sound better than they are. In fact, if you
> know then key and cipher (= E_k) and only two adjactent plain text blocks
> p(n-1) and pn, then you know ahead of time what the cipher block cn will be.
If you know the key, nothing much else matters at all...
> Hence, the complexity is increased compared to ECB mode, but not that much.
The basic fact is simple: if you encode identical text blocks, the
result won't end up identical. This prevents things like replay
attacks or simply drawing conclusions about content based on seeing
blocks that are identifiable, even if you can't decrypt them (which
can happen with ECB).
> 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.
> It should also be noted that any cipher in OFB mode is vulnerable to any
> attack that works against OTPs (= one time pads)
And what exact attacks work against OTPs? I think what you really
mean is against Vernam Ciphers -- while a Vernam cipher is the most
obvious and perhaps the most common method of using an OTP, it's NOT
the only way. Just for example, if you used IDEA, and used a new,
random key for each block, you'd have an OTP. I'm not sure exactly
what attacks you have in mind, but I seriously doubt they work
against all OTPs.
>, and some of these attacks
> does not work against a cipher in ECB mode. Hence, for e.g. financial
> transactions one might argue that the order of preference should be CBC, CFB,
> ECB and lastly OFB.
One could argue almost anything -- ultimately, they were all designed
for the simple reason that there are situations in which each is
useful. Despite this, if I had to blindly pick a chaining mode to
use in a wide variety of situations, it would probably be CBC.
I probably shouldn't have ranked things at all -- while CBC is
probably the most versatile chaining mode, it's _strongly_
preferrable to make an intelligent decision based on the intended use
rather than follow a ranking done with no knowledge of the task at
hand. In any case, the difference between third and last is pretty
meaningless in any case: picking either should normally be done only
for good reason, and if you know a good reason to use it, then some
blind ranking of preference doesn't mean much anyway.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Gray Code like
Reply-To: [EMAIL PROTECTED]
Date: Sat, 25 Mar 2000 02:07:37 GMT
[EMAIL PROTECTED] wrote:
: What I'm looking at here is a list of code words where a new symbol is
: shifted in from the right when you move to the next code word and all
: codewords are unique.
[snip]
: My question is if anyone knows what this kind of encoding is called and
: if there is any litterature about it and its uses.
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.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Superior firepower is invaluable when negotiations start.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Hashes! (newbie question)
Date: Fri, 24 Mar 2000 19:34:30 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ sorry to follow up to my own post, but... ]
> When/if there's good reason to believe an attack on an 80-bit space
> will become feasible reasonably soon, it seems fairly easy to imagine
> combining hashes, such as using both SHA-1 and RIPEM to produce a
> 160-bit overall result that you actually sign.
That should, of course, say "320-bit".
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Richard Lee King Jr." <[EMAIL PROTECTED]>
Subject: Re: rc-5 plaintext guess.
Date: Sat, 25 Mar 2000 03:07:24 GMT
sorry, but i never ever use caps.
that would imply that i am either dexterous
or else have two hands.
99% of my making hours, one hand is occupied
by a cigarrette, and no, i'm not dexterous.
in fact my vision is so poor that i can barely correct
my spelling. as far as guessing the plaintext goes,
without the key, it could be anything.
so my guess is as good as any.
i am trying to find a formula to determine if a
guess for a given half of a block is correct.
i may find something eventually.
"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.
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network
*
> The fastest and easiest way to search and participate in Usenet - Free!
>
------------------------------
** 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
******************************
