Cryptography-Digest Digest #428, Volume #11 Mon, 27 Mar 00 05:13:00 EST
Contents:
Re: NIST publishes AES3 papers (Scott Contini)
Re: SCRAMDISK - Question on uncreating a scrambled partition or how to (Jill)
Re: Mixing N bits into N bits (Mok-Kong Shen)
Re: Download Random Number Generator from Ciphile Software (Anthony Stephen Szopa)
Re: Download Random Number Generator from Ciphile Software (Anthony Stephen Szopa)
Re: Applied Zero Knowledge Proof ("Reuben Sumner")
Re: OAP-L3: Answer me these? (Taneli Huuskonen)
Legal Opinion advises use of steganographic filesytems in UK ("NoSpam")
Re: Hashes! (newbie question) (Mark Wooding)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: NIST publishes AES3 papers
Date: 27 Mar 2000 07:33:51 GMT
In article <#RRlxi7l$GA.206@cpmsnbbsa03>,
Joseph Ashwood <[EMAIL PROTECTED]> wrote:
>RC6 is apparently secure for now, but with even the tiniest
>progress on an attack, RC6 will fall. If a new attack is
>found RC6 doesn't necessarily have the security margin to
>deal with it, where any of the others have enough margin to
>make it more likely that they will remain secure. All
>currently known attacks have been applied to every AES
>finalist, so RC6 has no demonstrable advantage in that
>respect, except perhaps in that it doesn't require more than
>the minimal amount of time to resist the attacks.
Attacking ciphers is more complex than you make it out to be.
It is not so easy to just say that you tried differential or
linear cryptanalysis on a cipher. What is more important is
how you tried the cryptanalysis - for example, what notion
of difference did you use, or did you consider linear hulls,
or linear cryptanalysis using multiple approximations.
Attacking a cipher takes years of analysis - the benefit with
RC6 is that is based upon years of analysis of RC5 that the
research community has participated in. This is not to say that
it is guaranteed to be totally secure (certainly none of the
AES candidates are), but it is perhaps more comforting to
choose a cipher that is based on years of cryptanalysis experience.
That is one of the issues that needs to be taken into consideration
when choosing the next AES.
>
>I do not see where RC6 is any more studied than any of the
>others, it is quite simple to establish that the changing of
>the smallest detail of a cipher can make it weaker, in the
>case of RC5 to RC6, the enhancements were carefully chosen,
>but it is a new cipher, and as such it needs to be
>considered as a new cipher. Yes it will inherit strength
>from RC5, but all attacks need to be reevaluated, and new
>lines of attack may have been created. For the final
>decision of AES I should hope that consideration of security
>margin against potential future attacks is considered. We
>all pretty much agree that we don't know everything about
>cryptography yet, why should we trust a cipher that has a
>security margin of virtually nothing?
> Joe
>
The question is this: do you prefer a totally new cipher with
an apparently large security margin, or a cipher based on something
that has previously been well studied and the previous attacks don't
seem to apply on to the new cipher?
Apparently your opinion is to immediately accept the new ciphers
as better, and to dismiss RC6 as hollow. However, you should be
aware that many people have different opinions, and calling a
cipher hollow because of your opinion is not a fair statement.
Scott
------------------------------
From: Jill <[EMAIL PROTECTED]>
Subject: Re: SCRAMDISK - Question on uncreating a scrambled partition or how to
Date: Mon, 27 Mar 2000 08:45:40 +0100
Have a look at the Scramdisk newsgroups the Author and other experts
regularly write there, they will be able to help you.
alt.security.scramdisk
I don't use the partition option and I haven't got scramdisk on my work
machine (were I am now) but from memory:- The preferred drive letter
option works fine when you use a container file, once you enter your
preferred drive letter you must hit the 'update' button before 'OK' then
dismount and remount the Scramdisk.
To convert the partition to unscrambled drive I think you right click on
the partition information in the Scramdisk Window and click 'revert to
DOS'
Hope this helps,
Jill
John-Erik Horn wrote:
>
> Hello All!
>
> Tried out Scramdisk today. It's quite alright. I have two questions that I
> cannot answer in the manual (read it completely).
>
> How can I force Scramdisk to define the scrambled partition as drive E. for
> example?
>
> If this is not possible, I would like to restore that partition back to an
> unscrambled drive.
>
> Scramdisk 2.02h
> Win 98 on a PII 350
>
> I have successfully created a scrambled partition (was my drive E:), now it
> shows up as the last drive (N:) and the preferred drive definition has no
> effect.
>
> Thanks.
>
> J-E
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Mixing N bits into N bits
Date: Mon, 27 Mar 2000 10:11:33 +0200
stanislav shalunov wrote:
>
> The basic idea is that you split your 32-bit value in two halves, L
> and R, and then apply the following transformation a few times:
>
> TEMP <- L
> L <- R
> R <- TEMP XOR F(R, K)
>
> K is your (symmetric) (sub)key, which doesn't have to be secret for
> your application. Key usually changes from round to round, but you
> don't have to worry about this. F is a function that's as complicated
> as you can think of.
>
> > BTW, would "hash" be a proper word to call what I just described?
>
> Hash usually works on arbitrary length data, and thus collisions are
> unaviodable. You require a function to be 1-to-1, and only map 32-bit
> ints into themselves.
>
> The Feistel network trick described about lets you turn any function
> F: {0..2^32-1} -> {0..2^16-1} into such 1-to-1 function. Depending
> on number of rounds, properties of F and key schedule the function
> can mix better or worse.
What properties must F satisfy in order that your function based
on the Feistel construction is 1-1? A F that maps everything to 0
certainly wouldn't do. Would an arbitrary surjective mapping
{0..2^32-1} -> {0..2^16-1} do that? Could you give a proof of your
assertion? Thanks.
M. K. Shen
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Download Random Number Generator from Ciphile Software
Date: Mon, 27 Mar 2000 00:20:34 -0800
Taneli Huuskonen wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> In <[EMAIL PROTECTED]> Anthony Stephen Szopa
> <[EMAIL PROTECTED]> writes:
>
> [...]
> >array files. Rotate Set3 and the state of the primary array files
> >change and this will change the state of Set4 and Set5. Also,
>
> According to your Web page, you rotate Set1 rather than Set3, which
> obviously leaves Set4 unchanged. However, this is a minor nit; if you
> fixed this glitch in the obvious way, essentially the same problem would
> remain.
>
> [...]
> >No MEANINGFUL relationship(s) such as the ones you suggest above can
> >be made. You can write the relationships symbolically, but knowing
> >only the data we assume we have, these relationships cannot be
> >quantified. They remain variables or place holders waiting for
> >values which cannot be determined.
>
> Here's an excercise. Pick three permutations of the numbers 0..9, say
> P1, P2, and P3. Form P4 by using P2 to index P1, P5 by using P3 to
> index P4, P6 by using P3 to index P2, and P7 by using P6 to index P1.
> Assuming we only know P7, the value of any one of P1, P2, P3, P4, or P6
> could be anything. How about P5?
>
> Just do it for real, and you might learn something.
>
> Taneli Huuskonen
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
>
> iQB1AwUBON5hSwUw3ir1nvhZAQEC2wMAwiHc1DDNK7PC2XNuhti+hHp3bAcvppDT
> E9no4LHfAM0ul7NZ+Wb4l7PkMJbouHrQMEvzwaNWDKxlbNVZfFQY4S5NqC7acfnl
> 3BA0qqlR6TXztRSZ8PSQWLRA9ByJep6+
> =0mG3
> -----END PGP SIGNATURE-----
> --
> I don't | All messages will be PGP signed, | Fight for your right to
> speak for | encrypted mail preferred. Keys: | use sealed envelopes.
> the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
Here is my concise reply:
My post was an attempt to answer your proposition that perhaps the
permutations in the three set files could be determined thus making
possible predicting the output to the random digit generator.
In the spirit of good sportsmanship, I agreed to entertain your
idea that if you had access to several megabytes of raw random
digits directly from the random digit generator that you could
determine the permutation sequences to the three set files.
My idea was that if I could show that even with the raw random
digits directly from the random digit generator, that it still was
not possible to determine the array sequences of the set
files, then it certainly would not be possible to determine the
array sequences to the three set files if you had only the random
numbers generated that form the OTPs (these numbers being the
triplets 000 - 255.) If this were the case then you could not
possibly crack messages encrypted using these OTPs. (You see,
you have more information with the raw random digit output
directly from the random digit generator than you get with from
the random numbers (0 - 255) generated by the software.)
So this is what I attempted to do for argument's sake:
demonstrate that even with the raw random digits directly
from the random digit generator that you still could not
determine the array sequences in the three set files simply
because you would still not have enough information.
(Let me mention here that if you could have access to the
raw random digit output directly from the random digit
generator then you should find it just as easy to get the
array sequences of the set files to begin with thus having
no need to attempt to crack the random digit generator. But let
us continue anyway.)
You mention correctly that it is indeed Set1 that is rotated but
my argument is just as valid: although you may know the random
output digit and what the element was that was read from Set5,
you do not know what the digit was that was read from Set5 so
even though you know what the digit is from Set4, you do not
know what element it came from in Set4. So you can never
reconstruct Set4 or Set5. Without knowing Set4 and Set5 you are
finished.
Now either you are trying to take advantage of me and trying to
confuse other readers, or you are crazy, because now you are
suggesting that you know one of the arrays ("Assuming we only
know P7".)
If you know P7 you must have had access to the other array
set files so you do not need to determine the set array sequences.
Are you abandoning your original proposition and now have opted
to give yourself access to the array sequences themselves? I
thought this is what you were trying to determine from your
perfect knowledge of the random digit generator and knowing
the raw random output digits from the random digit generator?
If so, then why discuss cracking the random digit generator since
you have access to the set arrays which were what you were trying
to determine by cracking the random digit generator in the first
place by using your knowledge of the software and the random output
digits?
So now the essential question is are you trying to take advantage
of me and trying to confuse other readers, or are you crazy, or is
there some other unimagined reason for you to have abandoned your
original proposition?
The original agreement was that you only have knowledge of the
random digit generator and you have the raw random digit output
from the generator. (In reality this would NOT most probably be
the case.) And you suggested that this is all you would
need to crack the random digit generator.
Since now you claim knowledge of the arrays you have nothing to
crack. Having the arrays is tantamount to having the key.
You have been judged to have forfeited the argument unless you can
explain this.
(Let me also mention that I had said that in order to solve
simultaneous equations you need more equations than you have
variables. This is not so: you only need as many equations
as variables to solve simultaneous equations.)
Like Spock said: "Usually evil triumphs over good unless good is
very good."
With the facts as they are it takes a lot of nerve to tell me:
"you might learn something."
I hope you have now learned something.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Download Random Number Generator from Ciphile Software
Date: Mon, 27 Mar 2000 00:45:39 -0800
Boris Kazak wrote:
>
> Anthony Stephen Szopa wrote:
> *************************************
> > What would you say if there were no attacks possible against
> > OAP-L3 when used according to recommendations (truly random user
> > input and large key length) except brute force?
> > **************
> > I believe that I can prove my point mathematically. It is straight
> > forward probability theory. I'm working on this proof.
> ========================
> I would say that you are a god, that other people must worship you
> and take at face value everything that you ever say.
> And since up to now you have not said anything of substance,
> except these humoristic declarations, please remember one rule:
>
> The power of any god is proportional to the number of his
> followers. In this sense your power == 0, since I did not see
> any followers of your faith voice their belief, let alone
> come to your help, explain the confused issues, etc.
>
> Best wishes BNK
Keep this in mind: It is better to be proven wrong in these news
groups than on the battle field.
I do not need believers. Heaven's Gate had many believers.
I have presented you with the information. I have required nothing
of any of you.
Finding any fault in the theory of OAP-L3 is proving quite
difficult. No one has suggested a reasonable approach with
support on how to crack OAP-L3. Only hand waving has been
offered. Because of OAP-L3's simplicity this is significant.
OAP-L3 has some very good attributes: it uses no mathematical
equations, it is easily understood, no specialized knowledge
required, it is very simple, no faith required, etc.
Perhaps you would like to be the first to demonstrate with some
sort of a proof that the OAP-L3 theory is bunk?
You will acquire a permanent blush from all the praise you will
get from many of those in this news group if you can debunk the
theory that OAP-L3 is based on with some sort of a proof.
Lastly, concern yourself with your own deification since you are
prone to such thoughts.
------------------------------
From: "Reuben Sumner" <[EMAIL PROTECTED]>
Subject: Re: Applied Zero Knowledge Proof
Date: Mon, 27 Mar 2000 10:23:48 +0200
Bit commitment doesn't solve the problem at all. This is just a password
problem where the biometric fingerprint (fingerprint in the more general
sense, including retinal scans or anything else). The EKE family of
protocols is, from my limited understanding, the state of the art.
Reuben
Bob Silverman wrote in message <8bdj1h$5m3$[EMAIL PROTECTED]>...
>In article <8bdge3$2h4$[EMAIL PROTECTED]>,
>Nelson Junior <[EMAIL PROTECTED]> wrote:
>> Bob,
>>
>> Suppose I have an unique sequence of bits. I cannot change this
>> sequence, it is static.
>>
>> So, I need a scheme to allow another party to confirm I have this
>> sequence without giving him the sequence itself.
>
>Just apply any standard bit commitment scheme. See Schneier's book.
>
>
>
>>
>> Please excuse me for my English. My native language is portuguese.
>
>Please accept *my* sincere apology. I did not realize this when I
>first posted.
>
>
>--
>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: [EMAIL PROTECTED] (Taneli Huuskonen)
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: 27 Mar 2000 12:16:39 +0300
=====BEGIN PGP SIGNED MESSAGE=====
In <[EMAIL PROTECTED]> Jerry Coffin
<[EMAIL PROTECTED]> writes:
>In article <8bmaob$m01$[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] says...
>[ ... ]
>> Just to be technically accurate: there is a third possibility -- he doesn't
>> know the level of detail an algorithm needs to be specified, and so he
>> honestly thinks that the very rough outline on his web page is sufficient.
>I can't go along with this one. People have repeatedly pointed out
>that his explanations are inadequate, including specific examples of
>the problems. Thus, to remain ignorant of the problems, we basically
>have to postulate that he either doesn't read or can't understand
>these messages. He's replied to enough of them to prove that he
>reads them, and in many cases the required comprehension level is
>well below that of messages he sends in reply. In short, he's
>disproven this possibility.
IMHO, much of the criticism has been missing an important point. Mr
Szopa's explanations make much more sense if you don't insist that they
describe a single cryptographic algorithm. You may think of each of the
"processes" as a standalone programme. Then the "key" would be a
sequence of commands like this:
run programme blah with parameters blah blah blah
run programme duh with parameters duh duh duh
...
The parameters include names for input and/or output files, sequences of
small integers, and possibly something else (I'm too lazy to check).
The exact format in which the user enters the "key" is left unspecified,
but that doesn't really matter. There's a facility to store the key in
a file, which can be copied and delivered securely to the recipient.
The main problem one would face in trying to write a compatible
programme is the lack of documentation on the AutoFile format - it's
only hinted at in the help file called "AutoFile tutorial". Some light
reverse engineering would be needed.
This sort of design, where the end user is responsible for choosing the
exact sequence of "processes" to run, makes meaningful assessment of
cryptographic strength quite hard, in any case. It'd probably be easy
to break a key containing just one process - would that count as a
weakness?
Taneli Huuskonen
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQB1AwUBON8m7gUw3ir1nvhZAQF6fgMAkOUudNbpFzu5QyNyabH+uxj5SMEA+epn
2yyh2P17UBjOrF+CQ1EPtN8cq9iAH6GaW2fbLsPnuEim1h75paGDkRlmrTf7E9Ws
UF23kGl5rtM6iUmfuRtCTu8ERsfODodQ
=bdv7
=====END PGP SIGNATURE=====
--
I don't | All messages will be PGP signed, | Fight for your right to
speak for | encrypted mail preferred. Keys: | use sealed envelopes.
the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
------------------------------
From: "NoSpam" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Legal Opinion advises use of steganographic filesytems in UK
Date: Mon, 27 Mar 2000 10:35:51 +0100
22nd March 2000
POLICE DECRYPTION POWERS FAIL HUMAN RIGHTS AUDIT AGAIN
JUSTICE, the legal human rights organisation, and the Foundation for
Information Policy Research today (Wednesday, 22nd March) warn that those
aspects of the Regulation of Investigatory Powers Bill dealing with police
powers to unscramble encoded e-mail are likely to breach human rights
standards under the European Convention on Human Rights.
Part III of the Bill (previously in the Electronic Communications Bill)
allows the police to serve written notice to demand either that a
communication be decrypted or the private encryption key be handed over.
According to an Opinion obtained from two leading lawyers, the Government
has wrongly opted for the widest police powers enabling open-ended
interception of encrypted material. It says that this "will have the
inevitable consequence of compromising the affected individual's whole
security and privacy apparatus" and thereby likely contravene Article 8 of
the European Convention on respect for private life.
In a second, up-to-date Opinion on Part III of the RIP bill, a number of
potential human rights breaches are again emphasised:
· The presumption of innocence is violated: failure to comply with a
decryption notice will be a criminal offence unless the person can prove
that s/he does not have the key, or does not have access to it because, for
instance, the password has been forgotten. This contravenes an important
element of the fair trial right guaranteed by Art 6 ECHR: that it is for the
prosecution to prove the offence, not for the defendant to prove his or her
innocence.
· The right not to self-incriminate is infringed: It is impossible
for the police to prove by technical means that the defendant 'has'
possession of the key. And, the only way of proving that he 'has had' the
key is by way of an admission by the defendant. Furthermore, disclosure of
the key by the defendant may lead to the discovery of incriminating
material. This contravenes a person's right to remain silent and not to
contribute to incriminating him/herself as guaranteed under the fair trial
right of Art 6 ECHR.
· There are inadequate safeguards against abuse: Not all decryption
notices have to be first authorised by a judge. There is no requirement that
the notice be restricted to serious crime; it could therefore be used for
low-level criminal data gathering. There are inadequate safeguards on the
holding of the decryption key and any material obtained. There is no
requirement to inform the Covert Investigations Commissioner that such
notices have been served. These are all requirements necessary to safeguard
privacy rights under Art 8 ECHR.
As the Opinion concludes:
'The above would suggest that for anyone using encryption, in order to avoid
unjustified suspicion and possible wrongful conviction, it would have to be
good practice to
a) Use steganographic file systems or equivalent technology; and
b) Not to admit to ever having had a key rather than be helpful and
co-operative.
For the vast majority of individuals this is counter-intuitive and for
society in general counter-productive.
Madeleine Colvin, Legal Policy Director at JUSTICE, said today:
"As these are significant breaches, we expect the Home Office to engage in
open debate on how far this Bill will fail to be human rights compliant in
practice, rather than merely asserting that it is".
Caspar Bowden, Director of the Foundation for Information Policy Research,
said:
"The question of the reversal of the burden of proof has been festering for
eight months. It is now time for the Home Office to give a reasoned
explanation for how an innocent person who has forgotten their key can be
expected to prove this on a balance of probabilities".
Notes to Editors:
1) This additional Opinion is written by barrister Tim Eicke (from Essex
Court Chambers). It updates the joint Opinion of Professor Jack Beatson QC
(formerly a Law Commissioner) and Tim Eicke on similar decryption powers in
the 1999 draft Electronic Communications Bill. A full copy of this Opinion
is at http://www.fipr.org/rip/ripaudP3.html and a copy of the original at
http://www.fipr.org/ecomm99/ecommaud.html or from the JUSTICE office
(tel.no: 0171 320 5100)
2) The Regulation of Investigatory Powers (RIP) Bill was introduced in
Parliament on Feb 10th and is currently in Committee in the House of
Commons. Background briefings, press cuttings, and policy history on the
Bill can be found at http://www.fipr.org/rip
3) JUSTICE is a human rights organisation that is currently undertaking
audits of the compatibility of proposed legislation with the Human Rights
Act 1998. In 1998, it published a major report on covert policing: 'Under
Surveillance: covert policing and human rights standards'. Detailed
briefings on other parts of the RIP Bill may be obtained from the JUSTICE
office.
4) The Foundation for Information Policy Research is the a London-based
Internet think-tank that studies the interaction between information
technology and society, and promotes public understanding and dialogue
between technologists and policy-makers in the UK and Europe. FIPR's
analysis was quoted six times in the Second Reading debate on the RIP Bill.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Hashes! (newbie question)
Date: 27 Mar 2000 09:45:41 GMT
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> 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?
I think they're `excuses' (OK, a poor choice of word) in the sense that
we don't accept lines like `well, it's not really ever-so practical in
most cases, is it now?' when faced with related-key attacks against
block ciphers whereas, it seems, we do with hashes.
> > 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.
Oh, yes. I understand all this. I didn't think it necessary to spell
out in detail, though.
> > 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.
I think you're being selective here. You're only describing algorithms
which have (or will have) little FIPS numbers attached to them.
However, it's interesting to note the recent bits of FIPSery and analyse
their rated security. Skipjack, according to Eli Biham's results, seems
to have a very carefully judged 80 bits of strength. SHA-1 offers 80-
bits-worth of collision resistance. DSA-1, with 160-bit q, offers 80
bits of strength against forgery. The KEA, defined with Skipjack, uses
a 160-bit q too, so is also 80-bits strong. This doesn't look like a
coincidence: it looks as if someone has made a policy decision that 80
bits of strength is enough for this sort of Government use and carefully
made a symmetric cipher, key-exchange algorithm, collision-resistant
function and digital signature with that security level. And I think
that makes sound sense.
I'm less sanguine that 80 bits is enough. If we stray from what's
FIPS-certified and look at what's in general use then we can see that
we've got more than enough apparently good symmetric ciphers: 128-bit
RC4, IDEA and Blowfish all look solid, and triple-DES to fall back on at
the expense of a performance penalty. Diffie-Hellman, RSA and DSA[1]
will all scale to provide whatever security we want from them, assuming
that no completely new attacks on these systems appear. The piece
missing from the picture is a commensurate hash function.
I mentioned DSA in both sections. I don't believe I'm being
inconsistent. In the former case, I was referring to the FIPS standard
for DSA, which mandates a 160-bit q, and therefore can offer no more
than 80 bits of security against Pollard's rho. The official DSA (and
KEA for that matter) are restricted by specification, rather than by an
inherent limitation in the design, as I suspect is true of Skipjack and
SHA. In the latter case, I'm thinking about a slightly generalized DSA
with no restrictions on q. In particular, picking a 256-bit q (and a p
to match) gives 128 bits of security as required.
> 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.
We already have good solid 128-bit ciphers. Admittedly block sizes are
too short and codebook recovery is looking less madly impractical than
it used to, but they work quickly and well. IDEA is encumbered but
Blowfish is free, faster, and has built up a good reputation for itself
and its designer. RC4 resists codebook recovery by not having a
sensibly-sized (conceptual) codebook to recover, although (I believe I'm
right here) its legal situation is still bizarre.
The widest hash function I've seen is Biham and Anderson's Tiger, at 192
bits, and it doesn't seem to be catching on, which is probably a shame.
I shall try implementing it tonight and see whether I like its
structure.
I don't propose to say anything more on the subject, because I can see
that I'm rehashing the same old stuff over again and becoming rather
dull.
-- [mdw]
------------------------------
** 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
******************************
