Cryptography-Digest Digest #118, Volume #12 Tue, 27 Jun 00 18:13:00 EDT
Contents:
Re: Thoughts on "Cracking" of Genetic Code (rick2)
Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
Re: TEA question ("Adam Durana")
Certificate authorities (CAs) - how do they become trusted authorities ??
([EMAIL PROTECTED])
Re: On a notation issue of Feistel ciphers (Mok-Kong Shen)
Re: Remark on practical predictability of sequences (Mok-Kong Shen)
Re: Idea or 3DES (JPeschel)
What's matter with http://tomstdenis.com/crypto/ ? ("�������� ������")
Re: Observer 4/6/2000: "Your privacy ends here" (Andy Dingley)
Re: Variability of chaining modes of block ciphers (Shawn Willden)
Re: Idea or 3DES (Jim Gillogly)
Re: Compression and known plaintext in brute force analysis (restatements caused by
the missing info .... thread) (wtshaw)
searching for a special GUI crypto tool ("TL")
----------------------------------------------------------------------------
From: rick2 <[EMAIL PROTECTED]>
Subject: Re: Thoughts on "Cracking" of Genetic Code
Date: Tue, 27 Jun 2000 19:19:05 GMT
In article <mJ665.2341$[EMAIL PROTECTED]>, "Adam Durana"
<[EMAIL PROTECTED]> wrote:
> I'm no expert on this subject but I believed they used one method
> cryptanalysists do use. They would introduce a change into the DNA and
> see
> how that affected the animal that was created from that DNA. So in a
> sense
> they altered the plain text (DNA) just a bit then let nature do its work
> to
> produce the cipher text (the living creature) and see what changes in the
> cipher text resulted from the change in the plain text.
True. You can make a mutation in a mouse ES cell that ablates or
alters a gene, then generate a live mouse carrying that mutation
in its germline to analyze the effects. Takes about 1-2 years and
$50-100,000 for each different mutation. Talk about brute force!
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Tue, 27 Jun 2000 21:36:47 +0200
Shawn Willden wrote:
> Mok-Kong Shen wrote:
>
> > > I suspect that it can't exist. Indeed, I suspect that, if we know our
> > > adversary's capabilities that accurately, we probably don't need
> > > cryptography at all, because we can determine a communication channel
> > > which is already secure against him.
> >
> > If you know the computer of the opponent, then you can calculate
> > the time for brute forcing.
>
> Can you? I think you can only calculate the maximum or average time, not the
> time it will take to brute force a given message. A better way to analyze
> this scenario is: Given a certain amount of computational power, there is a
> probability p(t) that the attacker can discover the key for a given message
> in time t.
>
> Call the useful lifetime of the message T. You're assuming, then, that p(T)
> is large, maybe p(T) = 1. Choosing among n chaining modes at best reduces
> the probability to p(T)/n.
>
> Can you be so certain that p(T) is an unacceptable risk, but p(T)/n is okay?
> Remember than n is small. Also remember that T is often hard to quantify a
> priori.
I see there is a general misunderstanding here. In my original post I
only point out that there exist many chaining modes and that hence one
could under circumstances change/vary one's chaining mode. This does
not exclude the case that one, after examining all the candidate modes,
determines to use one single mode permanently (though this may be a
different one than CBC, which is the commonly used mode). Certainly,
if one finds n modes to be o.k., then one could used these alternatingly
for different messages. But using n modes is only A possibilty. If that
is found not worth while, then one can drop that idea and choose one
mode (the best in one's opinion) to use.
> You keep referring to the situation in which the addition of a few key bits
> pushes the job of brute-forcing over some threshold which demarks what the
> attacker can or cannot do, but no such threshold exists, at least with
> respect to brute-force keyspace searches.
>
> The "threshold" is yours. Specifically, your level of acceptable risk; a
> notion that is notoriously hard to quantify precisely.
>
> To summarize, adding n key bits is useful when:
>
> 1. The attacker's capabilities are known (p(t))
> 2. The user's acceptable level of risk (R) is known
> 3. The lifetime (T) of the message is known
> 4. p(T) > R >= p(T)/2^n
>
> It's hard to imagine a scenario in which the imprecision of p(t), R and T
> don't swamp the risk interval created by a small n.
>
There can never be an objective and rigorous and precise risk analysis.
Subjectivity always plays a non-trivial role. But even then one could
do a rather sharp decision. In fact this is at the base of the so-called
subjective probability. One's subjective probability of the occurence
of an event can be determined through a game of bets (amounts of
win and lose) on the presumed probabilities of occurence. Perhaps
I should also say, concerning the small value of n (bits), that there is
at least one chaining mode where n is fairly large in my opinion. This
is the chaining mode using sums of both all preceding plaintext
blocks and all preceding ciphertext blocks, using two secret IVs.
M. K. Shen
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: TEA question
Date: Tue, 27 Jun 2000 15:15:38 -0400
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Adam wrote:
> > > yes..
> > > but if you choose different number it anyway should be 32 bit number
> > > so you cant use 1569234 - its too small - only 21 bit (1569234 ==
0x17f1d2
> > == 101111111000110110010 )
> >
> > You can put 1569234 into a 32-bit variable and that would work just
fine.
>
> realy? and if i put 5 into a 32-bit variable ? or even 1 or 0 ?
Its a constant, if you want to use 5, 1, or 0 then do it. But it is
possible to choose a bad constant, depending on how it's used. My point was
if what you said is true than no one should use a constant in a cipher if
its less than 2^(w-1) where w is the word size, 32 in this case. And that
is just simply not true.
------------------------------
From: [EMAIL PROTECTED]
Subject: Certificate authorities (CAs) - how do they become trusted authorities ??
Date: Tue, 27 Jun 2000 19:44:50 GMT
Hi,
In doing a bit of research on internet security I naturally came
across "Certificate authorities (CAs)" (ie: Verisign, twaite, etc) ...
can anyone tell me (or give me a URL) from where these companies get
*their* certification - who says they are 'trusted' ?? ...I suppose I
am asking as well what/who is the root of all authorities!
thanks,
Jay.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On a notation issue of Feistel ciphers
Date: Tue, 27 Jun 2000 22:01:32 +0200
Mok-Kong Shen wrote:
> tomstd wrote:
>
> > With three words you have an unbalanced feistel cipher. They
> > are not particularly usefull for encryption (but good as hash
> > functions). Check this out.
> >
> > A = A + F(C)
> > B = B + F(A)
> > C = C + F(B)
> >
> > Looks good because the previously modified word is going through
> > the F function the avalanche will be high... but let's look at
> > decryption.
> >
> > C = C - F(B)
> > B = B - F(A)
> > A = A - F(C)
> >
> > Now it's all backwards the previous word is not the input so the
> > avalanche is much less.
>
> Your last sentence is not very clear. Denoting the ciphertext with an
> apostorphe, the encryption and decryption are with your notation as
> follows:
>
> Encryption Decryption
> A' = A + F(C) C = C' + F(B')
> B' = B + F(A') B = B' + F(A')
> C' = C + F(B') A = A' + F(C)
>
> In the first set F operates once on an input block and twice on already
> processed blocks, while in the second set F operates twice on input
> blocks and only once on already processed block. I suppose you
> mean by this difference that there is less avalanche effects on
> decryption
> than encryption. However, while on encryption it is evidently desirable
> to
> have very good avalanche effect in order to maximize the uncertainty of
> determining from ciphertext bits the plaintext bits, it seems less clear
> why
> one needs very good avalanche effect in the direction of decryption.
> Perhaps you could give some convincing reasons. (I am not arguing that
> dividing into three parts is good though; see my original post.)
Addendum:
I think that your point of 'less avalanche' should be relativated.
Consider the normal Feistel cipher, i.e. with two equal parts. The
encryption for one big round is described by:
A' = A + F(B)
B' = B + F(A')
In your terminolgy B' will have better avalanche than A' (in the same
way as I mentioned above). Now for a big round A is at left and B at
right. Doing a number of big rounds doesn't change that fact. So one
would end up with the result that the left part of the ciphertext output
has poorer avalanche than the right part. The fact is however that, if
F is well designed, then with sufficient number of rounds there
shouldn't be any non-negligible difference in avalance of the two halves.
>From this we can see that an analogous situation should take place in
the case of division of the block into three equal parts. In other words,
with sufficient number of rounds and good design of F, the difference
in quality of avalanche between encryption and decryption should be
negligible.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Remark on practical predictability of sequences
Date: Tue, 27 Jun 2000 22:16:41 +0200
[EMAIL PROTECTED] wrote:
> To me this seems clearly true. But what are you getting at?
I mean one could eventually replace all hardware random sequence
generators with software, which is in my opinion more convenient to
use. (I heard much opinions that hardware generators are needed
because only these are secure against prediction/inference in practice.)
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Idea or 3DES
Date: 27 Jun 2000 20:09:08 GMT
"Joseph Ashwood" [EMAIL PROTECTED] writes, in part:
>Adding to this is the fact that DES is a couple decades old, and 3DES is
>heavily favored from an analysis point of view. There's also a downside to
>this, because DES is so popular as an algorithm, it is likely that various
>countries/large corporations have invested significant money in the analysis
>of it, the results of this analysis may or may not be published. It is my
>opinion that the likelihood of there being a significant known break in
>either is exemplified by the US Governments willingness to prosecute the
>author of PGP, indicating that neither is broken.
>
>However, we must also note that 3DES is a situation that was unconceived of
>for 3DES, perhaps a situation that it is poorly suited for, the immediate
>reduction from 168 bits to 112 (in terms of security) is a possible
>indication of just such a situation, this certainly has the potential to
>weigh in favor of IDEA. However, analysis of DES has shown that it does not
>form a 2-group, however we have not shown that it does not form a 3-group,
>at least as far as I know, but the likelihood of such an occurance is
>astroundingly low (again reinforced by the PGP case)
>
What does the prosecution of PRZ over PGP, which, at the time
of the initiation of the court case, used IDEA, have to do with DES?
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "�������� ������" <[EMAIL PROTECTED]>
Subject: What's matter with http://tomstdenis.com/crypto/ ?
Date: Tue, 27 Jun 2000 23:32:28 +0400
Hi!
About ten days ago I was on site http://tomstdenis.com/crypto/ where were a
lot of SUPER GOOD articles.
But now I can't connect to this link. What's the matter? Was this link
changed or where is these articles now?
Thanks, Michael.
------------------------------
From: Andy Dingley <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.security.scramdisk,uk.telecom
Subject: Re: Observer 4/6/2000: "Your privacy ends here"
Date: Tue, 27 Jun 2000 21:25:34 +0100
[EMAIL PROTECTED] (JimD) a �crit :
>>>>Maybe the webmaster's been assassinated by MI6.
>Absolutely. There was that woman from Shrewsbury they had
>murdered.
Hilda Murrell ?
------------------------------
Date: Tue, 27 Jun 2000 14:38:50 -0600
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Mok-Kong Shen wrote:
> Shawn Willden wrote:
>
> I see there is a general misunderstanding here. In my original post I
> only point out that there exist many chaining modes and that hence one
> could under circumstances change/vary one's chaining mode.
No, I don't think there's any misunderstanding here. I was not responding to your
original post, I was responding to a long chain of posts between you and
(primarily) Mark Wooding, in which you argue that there may be some value in adding
a few effective bits of keyspace by using a secret chaining mode.
> This does not exclude the case that one, after examining all the candidate modes,
>
> determines to use one single mode permanently (though this may be a
> different one than CBC, which is the commonly used mode). Certainly,
> if one finds n modes to be o.k., then one could used these alternatingly
> for different messages. But using n modes is only A possibilty. If that
> is found not worth while, then one can drop that idea and choose one
> mode (the best in one's opinion) to use.
That is an entirely different situation. Yes, the pros and cons of many modes
should be examined and one should choose appropriately. Of course, the fact that
using uncommon modes makes the life of the legitimate recipient more difficult
should also be considered.
> > You keep referring to the situation in which the addition of a few key bits
> > pushes the job of brute-forcing over some threshold which demarks what the
> > attacker can or cannot do, but no such threshold exists, at least with
> > respect to brute-force keyspace searches.
> >
> > The "threshold" is yours. Specifically, your level of acceptable risk; a
> > notion that is notoriously hard to quantify precisely.
> >
> > To summarize, adding n key bits is useful when:
> >
> > 1. The attacker's capabilities are known (p(t))
> > 2. The user's acceptable level of risk (R) is known
> > 3. The lifetime (T) of the message is known
> > 4. p(T) > R >= p(T)/2^n
> >
> > It's hard to imagine a scenario in which the imprecision of p(t), R and T
> > don't swamp the risk interval created by a small n.
>
> There can never be an objective and rigorous and precise risk analysis.
"Never" may be too strong, but I agree. That is precisely my point. Your risk
assessments are necessarily fuzzy. R is not a number, but a range, and it's likely
to be much larger than p(T) - p(T)/2^n.
> Subjectivity always plays a non-trivial role. But even then one could
> do a rather sharp decision. In fact this is at the base of the so-called
> subjective probability. One's subjective probability of the occurence
> of an event can be determined through a game of bets (amounts of
> win and lose) on the presumed probabilities of occurence.
This method can help you to determine a single value to place on your risk, but
possession of a representative value doesn't change the fact that risk is fuzzy.
Besides that, my main point is: How often does it occur that the value you select,
in whatever fashion, happens to fall between p(T) and p(T)/2^n? Assuming you can
quantify *those*, of course.
> Perhaps I should also say, concerning the small value of n (bits), that there is
> at least one chaining mode where n is fairly large in my opinion. This
> is the chaining mode using sums of both all preceding plaintext
> blocks and all preceding ciphertext blocks, using two secret IVs.
Now you're not talking about randomly selecting a mode to increase security, but
instead using secret IVs as additional key material. An analysis would be required
to determine how much security those secret IVs actually add. Obviously, there's
an easier attack than brute-forcing the IVs as well as the key.
Shawn.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk,comp.security.pgp.discuss
Subject: Re: Idea or 3DES
Date: Tue, 27 Jun 2000 20:44:51 +0000
Joseph Ashwood wrote:
> ... It is my
> opinion that the likelihood of there being a significant known break in
> either is exemplified by the US Governments willingness to prosecute the
> author of PGP, indicating that neither is broken.
Shouldn't you be arguing on the other side? The USG was in fact unwilling
to prosecute the author of PGP, so according to your analysis shouldn't that
indicate that IDEA was broken? I suggest that it's irrelevant to the
security analysis: that it was dropped because (a) they didn't have
strong evidence against PRZ himself; and (b) that they didn't want a
court to tell them that the ITAR were unconstitutional. I suspect further
that they didn't prosecute KG because of (b) and because he wasn't a
well-known enough target to serve as a horrible example to other potential
crypto hackers if they <did> manage to score a conviction without having
the ITAR thrown out in their entirety. Again, nothing to do with the
security of IDEA (nor, of course, [3]DES).
--
Jim Gillogly
Hevensday, 4 Afterlithe S.R. 2000, 20:39
12.19.7.5.18, 5 Edznab 1 Tzec, First Lord of Night
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Compression and known plaintext in brute force analysis (restatements
caused by the missing info .... thread)
Date: Tue, 27 Jun 2000 14:45:45 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> However, we are still in the stone age on this subject. Keying
> compression seems like an added complication at this stage. It's
> true that added complications can be of benefit in terms of resisting
> attack - but complications can have their costs as well. For the
> moment, I'd be inclined to KISS.
That is the way to start, but may not be the way to finish.
--
Ralph Nader must not be a politician, he makes sense. Those that
hype confusion about understandable issues are the anarchists.
------------------------------
From: "TL" <[EMAIL PROTECTED]>
Subject: searching for a special GUI crypto tool
Date: Tue, 27 Jun 2000 23:54:12 +0200
I'm searching for a special GUI crypto tool.
The aim is just to hide my private infos, when sending
email attachments thru the net, or even progs I made.
What I consider :
- it must work under all 32-bit Windows (win9x, nt4, w2k),
accepting LFN or multiple files' extension
- encrypting many files at once, and either getting the
same number of source files or (according to user's wish) only
a merged one
- coding many folders in recursive mode, such as compressing
when crypting, would be a plus
- (de)crypting may be invoke by a right-clic under EXPLORER,
if possible (instead of launching the appropriate tool in Menu Start)
- password must never be visible (remplaced by asterisks)
- possibility to definitively remove the source data when crypting
- english menus is the minimum (but french one would be OK too!)
- (de)crypting a 1Mb folder mustn't take more than 10 seconds
or so (on a P2-400MHz basis)
- poor password must be rejected (too short or evident ones)
- most of keyboard characters must be accepted.
- no backdoor (quick glance to programmers or hackers/crackers,
but do I have to write this? We all know what crypting risks are!)
- at last but not the least : the product must be freeware,
shareware, cardware or so (CRESUS has left us!)
Some downloaded binairies I like the most :
- PUFFER http://www.briggsoft.com/puffer.htm
- CRYPTO http://www.gregorybraun.com/crypto.html
- HARDCRYPT http://www.alternetive.asso.fr/securite/jcutils.htm
For those who like to crypt with WinZip, it has been proved to be
poorly protected (or with a long phrase, may be?)
Nothing to do with paranoia, but when looking inside the crypted files
with an hex-editor (header, or so), someone may easily deduice the
used crypting tool and have the correspounding antidote...
To be considered!
Thanks for those of you who have constructive comments,
or even better : URL's of matching softs such as indicated above,
on this NG or directly via my email.
______________________________________________________________________
[Thierry]
------------------------------
** 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
******************************
