Cryptography-Digest Digest #93, Volume #12 Fri, 23 Jun 00 12:13:00 EDT
Contents:
Re: Try it. (John)
Re: libdes: des_SPtrans (Svend Olaf Mikkelsen)
Re: Encryption on missing hard-drives (John Myre)
Re: libdes: des_SPtrans (Svend Olaf Mikkelsen)
Re: Try it. (Mark Wooding)
Re: libdes: des_SPtrans (Mark Wooding)
Re: Public key algorithm conversion - does it possible? (Mark Wooding)
Re: how to compare the securtity between ECC and RSA (Bob Silverman)
Re: Variability of chaining modes of block ciphers (John Myre)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
TEA-wmlscript question (dexMilano)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Re: breaking encryption - help! (Tim Tyler)
Re: Variability of chaining modes of block ciphers (Guy Macon)
Re: Variability of chaining modes of block ciphers (Guy Macon)
----------------------------------------------------------------------------
Subject: Re: Try it.
From: John <[EMAIL PROTECTED]>
Date: Fri, 23 Jun 2000 07:08:42 -0700
Keys are important in the analysis as well. Yes, it is not all
that important in the overall discussion, and probably reflects
bad writing, or the brain working faster than the hands.
I think None will now realize this:
1. Secrecy used to be good, in the days of the Cold War.
2. It was assumed secrets kept things secure.
3. Now it is just the opposite. If we have open-source, we can
eliminate the theft of Intellectual property, since all will
have to show the source, nobody can pull one over on someone
else.
That is the most compelling argument for public availability
aside from the analysis one.
Now, how do I get None and the other NDA people to put out there
source? I mean, how would they go about it? Where would they
release the source to?
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (Svend Olaf Mikkelsen)
Subject: Re: libdes: des_SPtrans
Date: Fri, 23 Jun 2000 14:11:31 GMT
[EMAIL PROTECTED] wrote:
>hi all,
>
>i'm porting a portion of libdes to a handheld terminal with very little
>code memory (32K). if i can get to calculate des_SPtrans table
>in "spr.h" i can save 4K, that makes 12.5%. does anyone know the
>algorithm to calculate the table? i ananlysed it for some time but
>could not get to an answer. thanks in advance.
Note that des_SPtrans is 2048 bytes, nok 4K.
--
Svend Olaf
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Encryption on missing hard-drives
Date: Fri, 23 Jun 2000 08:11:29 -0600
Guy Macon wrote:
<snip>
> What you don't need is to give the scientists access to the hard drives
> with the disarming instructions.
That can be tricky, since often the scientists play a part in
defining the instructions. That's not to say I know what's
going on in the Los Alamos case; just that, in general, you can't
rely on a simple division like the above. Otherwise, why would
the scientists have clearances at all?
John M.
------------------------------
From: [EMAIL PROTECTED] (Svend Olaf Mikkelsen)
Subject: Re: libdes: des_SPtrans
Date: Fri, 23 Jun 2000 14:13:46 GMT
[EMAIL PROTECTED] wrote:
>hi all,
>
>i'm porting a portion of libdes to a handheld terminal with very little
>code memory (32K). if i can get to calculate des_SPtrans table
>in "spr.h" i can save 4K, that makes 12.5%. does anyone know the
>algorithm to calculate the table? i ananlysed it for some time but
>could not get to an answer. thanks in advance.
Note that des_SPtrans is 2048 bytes, not 4K.
--
Svend Olaf
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Try it.
Date: 23 Jun 2000 14:36:55 GMT
John <[EMAIL PROTECTED]> wrote:
> 1. Public availability, as you say, I think, won't guarantee
> security,
Indeed not. But if you have lots of people looking at your system, it's
more likely that one of them will notice and tell you (and, possibly the
rest of the world, but hey, you can't have everything). Whereas if you
keep the system a secret, you'll keep the `white hat' people away, while
the `black hat' people will be quite happy to reverse-engineer your
work, find holes in it, and exploit them rather than letting you know.
But I'm not sure I was talking about security itself. I think I was
talking about *trust* in security. I, as a potential consumer of your
security system, want to as sure as I can be that it will meet my needs.
If I know, for example, that it uses established cryptographic
algorithms and protocols, and I can see a strong security architecture,
then this increases the level of trust I'm willing to give the system.
If it uses new, but public, cryptography protocols and other components
then at least I can analyse them, and get other people to analyse them,
and I might be willing to grant a limited amount of trust. But if it's
a secret black box, I can't trust it at all.
> A better way to be sure if an algorithm/source code is good/secure,
> would be some courses in computer programming.
Erm, no, not really. It's an absolute prerequisite that you know what
you're doing. But even the experts make mistakes. That's why review is
so important.
> 2. I am confused, what part of the source would one get an NDA
> for? If you can't "protext" your encryption, the rest hardly
> seems worth protecting.
I don't know whether your `encryption' is symmetric or public-key. It
doesn't really matter: there are many established and respectable free
algorithms for both. There are symmetric ciphers such as triple-DES,
CAST, Blowfish and the AES algorithms such as Serpent, Rijndael and
Twofish. We have asymmetric algorithms such as ElGamal, DSA, and (come
September, or outside the USA) RSA, together with some elliptic curve
variants of these. I honestly don't think that, for general-purpose
use, you have much scope for improving on these significantly. (You
might be able to make more headway with a new public-key scheme, but
you're best off making that public so that it can be used in protocols
such as TLS.)
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: libdes: des_SPtrans
Date: 23 Jun 2000 14:44:11 GMT
Eric Young <[EMAIL PROTECTED]> wrote:
> I used to have a perl script that generated the table, unfortunately I
> lost it years ago (simple enough to reconstruct though).
Indeed.
As a matter of policy, I decided that I'd derive tables which were
derivable rather than arbitrary as part of my build process.
> I believe one reason the libdes table is probably different is that I
> went 'little-endian' in the table conversions. Most other people tend
> to be big-endian.
Yes, that would probably be it.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Public key algorithm conversion - does it possible?
Date: 23 Jun 2000 14:48:06 GMT
acoola <[EMAIL PROTECTED]> wrote:
> Conversely conventional using of a public key algorithm I'd like to
> conceal public key from everybody and make private key available for
> anyone so only I be able to encrypt a message. May I use ElGamal for
> that? How is difficult to deduce ElGamal's public key knowing private
> key, chipertext and plaintext?
It's trivial to derive an ElGamal public key from the private key. If
the prime modulus is p, the generator is g, and the private key is x you
compute the public key as g^x mod p.
What's the difference between what you want to do and a digital
signature?
-- [mdw]
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: how to compare the securtity between ECC and RSA
Date: Fri, 23 Jun 2000 14:38:56 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> As I keep saying, given TIME to break a symmetric key is difficult to
map to
> SPACE to break an asymmetric key. It is straightforward to map time
to time.
> This is an advantage in the analysis.
There is nothing special about TIME. It is just one component.
If you *really* want to only compare on the basis of *one* variable,
why not equally just compare on the basis of SPACE and ignore time?
On this basis an EC key would have to be hundreds of thousands if not
millions of bits long to give the same security as 1024-bit DSA.
This too would be conservative. It is straightforward to map SPACE to
SPACE.
(BTW) I don't agree with this approach. To compare using only
TIME vs TIME or only SPACE vs SPACE is silly. This is a decision
problem. In a decision problem one must consider ALL constraints.
This is standard methodology in operations research, decision theory,
economics, etc. etc.
--
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.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Fri, 23 Jun 2000 09:08:19 -0600
Guy Macon wrote:
>
> Eric Lee Green wrote:
<snip>
> >In other words, complexity is to be avoided whenever possible because it is a
> >security problem. My opinion is that adjustable chaining modes (as vs. one
> >chaining mode) is added complexity whose cost-benefit margin is dubious.
> >
<snip>
> I conclude that, in this limited case, adding complexity does
> not increase the chance of bug or a security problem with your implementation
> hurting you, but rather decreases it.
<snip>
I agree with Eric (and so disagree with Guy). As I see it, the reason
that complexity can be a security problem is because of implementation
errors. That is to say, a bigger program, a more complex program, has
a higher chance of being implemented incorrectly. The idea that the
strength of part A is not reduced by adding part B only applies if the
chance of an implementation error in A is unaffected by adding part B.
I don't think it is reasonable to accept that premise.
The classic case is a pointer error in B which corrupts data in A. But
even if we assume that the implementation environment is perfect, and
does not allow this sort of interaction, real-world constraints will
mean that implementing B could reduce the quality of A even if B is not
included in the final product! I mean that the resources spent on B
(e.g., design, review, testing) will not be available for A, or for the
system as a whole.
In the case of variable chaining modes, I think the consensus of the
professonal paranoids would be that the theoretical strength added
(not a lot - and debatable) could not compensate for the possible
practical weakness (could even be fatal). Even adding a second
"strong" cipher is debatable, as a general principle; there would
have to be some reason (such as, we're protecting this data for
a hundred years, no trouble is too much, we'll spend as much as we
must to get it right).
John M
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Fri, 23 Jun 2000 17:31:13 +0200
Mark Wooding wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > You apparently forgot how the issue 'slightly larger key' came in the first
> > place. It was because you touched that point that we began to discuss
> > on that. Let me quote you:
> >
> > Why is this better than using a good cipher with a slightly
> > longer key in a standard chaining mode?
>
> Yes. So combine my points.
>
> * Using bizarre and randomly chosen chaining modes might, if you're
> lucky, give you a slightly larger key space. This might be better
> achieved by using a standard good cipher with a slightly larger key
> space and a standard, fixed chaining mode.
>
> * But there's not a lot of point in using a cipher with only a
> slightly larger key space. Either you're not worried by the
> cipher's key space, in which case extending it isn't useful, or you
> are, in which case a small increase doesn't help.
>
> See? There's glory for you.
Let me reiterate my points:
1. I showed that there are more than one chanining modes than what
is apparently commonly understood to be 'the' chaining mode. So,
if one doesn't want to use chaining mode or has no need of that
(because with his algorithm ECB is already o.k.), then one doesn't
need my stuff at all. Otherwise:
2. I showed that there are at least 8 variants, without giving comparative
valuation of these. I do have my personal favorites, but I refained
from saying anything about that in the original post, since I believe
that I might be too subjective and would like to hear others' opinions
about the comparative merits of the variants. So if your favorite is
e.g. CBC, and don't like to care others, I have nothing to object.
But if someone claims that CBC is the only best mode, then I do
like to hear his supporting arguments. Suppose this is not the case,
i.e. it is accepted that there are more than one chaining modes
that may be good enough for one's application, then I have argued
that, since the software implementation for enabling a choice of
these is according to my past experience quite straightforward,
that variability could in fact be easily exploited. Again that is merely
a suggestion. If one doesn't like to exploit that possibility (for
whatever reason, including laziness), then so be it. Suppose one
likes to exploit that advantage, then:
3. I argued that, even though exploitation of the variability in
question amounts only to a couple of bits of increase of key
space, it does have a good sense to do that in many situations,
because (a) switching to an algorithm that has greater key size,
e.g. doubled size, which certiainly obviates with one single
stoke the need of doing other little things to improve security,
may not be a viable option in certain environments, due to e.g.
unavailability of the larger algorithms or other non-crypto-related
reasons, (b) an improvement of a time factor of 2 or 3 may not
be trivial in respect of the chance of opponent's success, either
because his resource is already at the limit or because the
usefulness of the information is time-limited. BTW, I don't
understand why one belittles chances of getting small benefits.
In other contexts, I know, for example, plenty of people who
care much about the price differences among the supermarkets.
Evidently, tiny little savings do amount to something, though I
myself often neglect price comparisons (because I am too lazy,
not because I am not poor). As also discussed, all depends on
the cost-benefit curve. Now this curve is individually different.
I don't want to convince others to use my curve but I don't
accept on the other hand anyone claiming that his curve is the
single right one, since risk analysis can't after all be entirely
objective. Thus I leave it entirely open whether and how one
chooses from among the 8 (or eventually more) chaining modes
but can't accept on the other hand claims about inappropriateness
of using chaining modes or about desirability of use of one
particular mode, e.g. CBC, unless I can see clear and convincing
supporting arguments.
Please note that the above points have a sequential order. They
are to be processed in that order, otherwise one risks to be out
of the proper context.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Fri, 23 Jun 2000 17:30:43 +0200
Mark Wooding wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > It is because there are many of them, i.e. there exists variability,
> > that you are able to 'pick' one. Otherwise there is no 'picking'.
>
> By `pick one', I mean, `select a single, fixed chaining mode, and use it
> throughout your protocol'. Contrast this with secretly choosing and
> negotiating one of a suite of chaining modes during each connection
> setup.
One doesn't have to negotiate. If there is to be a choice among several
candidate modes that one believes to be good, one can do it in any
of the key-dependent ways (e.g. seeding a PRNG).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Fri, 23 Jun 2000 17:30:57 +0200
Runu Knips wrote:
> On the other hand, a good cipher should not be plaintext
> attackable anyway, so this is mainly an additional overhead,
> isn't it ?
Perhaps I may say my 'personal' opinion in using a cipher. I certainly
attempt to select the BEST cipher available under all the constraints
(economical etc.). Since I can't be entirely sure (may be due to my
specific psychological weakness) of the strength of it (because on
the one hand I don't have 100% trust on the crypto gurus and on
the other hand my own crypto knowledge is meager), I'll look out
for any practically available (and economically affordable)
supplementary measures to enhance its strength, no matter how
small these are. It may well be the case that my fear is unjustified,
because the cipher I use is indeed absolutely strong, but adding
these supplementary measures do help me to fall to sleep at
night easier (placebo effect?). So they are at least worth that
for me. I like to take this opportunity to once again stress that
I am not recommending to others to unconditionally exploit the
variablity of chaining modes but I only want to call attention to
the fact there IS a possibility of doing that, if one likes to look
after it.
M. K. Shen
------------------------------
From: dexMilano <[EMAIL PROTECTED]>
Subject: TEA-wmlscript question
Date: Fri, 23 Jun 2000 15:19:12 GMT
I've tried to implement TEA in wmlscript but I've found some problem to
assign the Golden number delta (= 0x9e3779b9).
In the wmlscript we have (signed) int a 32 bit so the range arrive to
7fffffff.
The question is: Is there a way to create a golden number minor than
7fffffff?
thx
dex
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Fri, 23 Jun 2000 17:45:16 +0200
John Myre wrote:
> I agree with Eric (and so disagree with Guy). As I see it, the reason
> that complexity can be a security problem is because of implementation
> errors. That is to say, a bigger program, a more complex program, has
> a higher chance of being implemented incorrectly. The idea that the
> strength of part A is not reduced by adding part B only applies if the
> chance of an implementation error in A is unaffected by adding part B.
> I don't think it is reasonable to accept that premise.
The reasonableness depends of course on the concrete case at hand.
I have in one of my own old designs implemented options of choosing
among (a) chaining with accumulated plaintext (b) chaining with
accumulated ciphertext (c) both, and I offered in addition an option
of selecting a chaining mode rather specific to my design. The code
involved turned out to be extremely simple and straightforward. So
the fear that adding that feature would compromise the integrity of
the whole encryption software package is unjustified in practical
terms in my conviction.
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: breaking encryption - help!
Reply-To: [EMAIL PROTECTED]
Date: Fri, 23 Jun 2000 14:57:40 GMT
Steve Basford <[EMAIL PROTECTED]> wrote:
: Andrew Carol <[EMAIL PROTECTED]> wrote:
:>Yet notice the leading "www." DO match. Perhaps they are employing a
:>carry from left to right between characters? Or some other feedback
:>system between characters.
:>
:>Another thing to try to is use a web address such as "aaaaaaaaaa.com",
:>"bbbbbbbbbb.com", and "cccccccccc.com" to see if there is a common
:>change which would suggest a simple carry.
: Okay, here you go...
: 0E
: 39 57 09 7D 19 0E F8 D4 AB 40 76 DE 33 B3 := aaaaaaaaaa.com
: 0E
: 3B F8 FF 99 91-B2 46 29 6A 65 6D E6 3D EA := bbbbbbbbbb.com
: 0E
: 3A 7D 7A C3 08 90 51 14 5B 16 44 A0 31 3B := cccccccccc.com
Something obvious: the first characters in the cyphertext increase
here as the plaintext characters are incremented.
Presumably this will not work for all characters - since "w" was
always mapped to 0x2F.
It /looks/ like the first character can be extracted by compiling a table.
This is what should probably be done first, and the table examined for
any pattern.
Then, hold the first character fixed (somewhere, anywhere), and do the
same with the second character.
Repeating this process may help to produce some illumination.
Something else to try - try modifying single characters slightly and
observing any regularities in the effect on the resulting (probably
subsequent) cyphertext.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Variability of chaining modes of block ciphers
Date: 23 Jun 2000 11:57:35 EDT
Trevor L. Jackson, III wrote:
>
>Guy Macon wrote:
>
>> Eric Lee Green wrote:
>> >
>> >Implementing *A* chaining mode is not the point. Been there, done that. The
>> >point is that every additional line of code is a line of code that could
>> >represent a bug or a security problem with your implementation. Past a certain
>> >point, the added security of globbing yet more code on top of code is
>> >illusionary.
>> >
>> >In other words, complexity is to be avoided whenever possible because it is a
>> >security problem. My opinion is that adjustable chaining modes (as vs. one
>> >chaining mode) is added complexity whose cost-benefit margin is dubious.
>> >
>>
>> (This is a general comment about adding complexity, not about the particular
>> methods discussed in this thread) It seems to me that, if a cipher is strong,
>> then it can protect any plaintext. Thus, if the plaintext to cipher B is
>> the output of cipher A, any bugs or security problems in cipher A won't
>> hurt you. Also, if a cipher is strong, then all known transformations of
>> it's output do not reduce the strength.
>
>All but one. Decryption does "reduce the strength".
>
>In fact one could conceive of transforms related to decryption such as performing
>an incomplete decryption of less than the normal number of rounds.
Ah. Forgive me for leaving out an essential part. I should have said that
if a cipher is strong, then all known transformations of it's output by
someone who does not have the key do not reduce the strength. An important
distinction.
>> Thus, if the plaintext to cipher B
>> is the output of cipher A, any bugs or security problems in cipher B won't
>> hurt you. I conclude that, in this limited case, adding complexity does
>> not increase the chance of bug or a security problem with your implementation
>> hurting you, but rather decreases it. I can make a similar case for adding
>> complexity in stream ciphers by using XOR to combine your plaintext with
>> the output of multiple ciphers.
I should add that, although the security will not be decreased, the cost
(in bits of key, time needed to encrypt/decrypt, etc.) will be increased
and thus the cost/benefit ratio might very well become worse.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Variability of chaining modes of block ciphers
Date: 23 Jun 2000 12:08:40 EDT
John Myre wrote:
>
>
>Guy Macon wrote:
>>
>> Eric Lee Green wrote:
><snip>
>> >In other words, complexity is to be avoided whenever possible because it is a
>> >security problem. My opinion is that adjustable chaining modes (as vs. one
>> >chaining mode) is added complexity whose cost-benefit margin is dubious.
>> >
><snip>
>> I conclude that, in this limited case, adding complexity does
>> not increase the chance of bug or a security problem with your implementation
>> hurting you, but rather decreases it.
><snip>
>
>I agree with Eric (and so disagree with Guy). As I see it, the reason
>that complexity can be a security problem is because of implementation
>errors. That is to say, a bigger program, a more complex program, has
>a higher chance of being implemented incorrectly. The idea that the
>strength of part A is not reduced by adding part B only applies if the
>chance of an implementation error in A is unaffected by adding part B.
>I don't think it is reasonable to accept that premise.
>
>The classic case is a pointer error in B which corrupts data in A. But
>even if we assume that the implementation environment is perfect, and
>does not allow this sort of interaction, real-world constraints will
>mean that implementing B could reduce the quality of A even if B is not
>included in the final product! I mean that the resources spent on B
>(e.g., design, review, testing) will not be available for A, or for the
>system as a whole.
Ah. Yes, if Code A can corrupt B as well as being flawed itself, then
security will be decreased. My question is this: how is this different
from running an unrelated program on the same computer? If A can corrupt
B, then so can Microsoft Word.
Perhaps we are making different assumptions. It sounds like you are
assuming one big program with algorithm A and B in it. I assumed two
entirely different programs running at different times and interfacing
only through a text file that contains the ciphertext from A which is
also the plaintext for B. It didn't occur to me to do it any other way.
>In the case of variable chaining modes, I think the consensus of the
>professional paranoids would be that the theoretical strength added
>(not a lot - and debatable) could not compensate for the possible
>practical weakness (could even be fatal). Even adding a second
>"strong" cipher is debatable, as a general principle; there would
>have to be some reason (such as, we're protecting this data for
>a hundred years, no trouble is too much, we'll spend as much as we
>must to get it right).
...Which accurately describes many of us hobbyists' use of crypto.
We don't need the extra strength any more than someone with a hot
rod needs those new injectors or your average golfer needs those
expensive new clubs.
------------------------------
** 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
******************************
