Cryptography-Digest Digest #918, Volume #11 Fri, 2 Jun 00 08:13:01 EDT
Contents:
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po (Nemo)
Re: Tableaus Revisited, Again (Mok-Kong Shen)
Re: Is it possible to use encryption to solve this problem? (Mok-Kong Shen)
Multiple exponentiation (ahbeng)
Re: PKware (PKZIP) Encryption (Runu Knips)
Re: Can we say addicted? (Runu Knips)
Re: Question about Re: RSA/PK Question (Mark Wooding)
Re: Anti-Evidence Eliminator messages, have they reached a burn-out po (Mark Wooding)
Re: XTR (was: any public-key algorithm) (Mark Wooding)
Re: Contest rule proposal (Mark Wooding)
Re: Powers of s-boxes and other functions (tomstd)
Re: Can we say addicted? (tomstd)
Re: No-Key Encryption (Mark Wooding)
Re: Question about Re: RSA/PK Question ("Trevor L. Jackson, III")
Weak Keys in TC3 (tomstd)
Re: Question about Re: RSA/PK Question ("Trevor L. Jackson, III")
Re: Contest rule proposal (Mok-Kong Shen)
Re: Contest rule proposal (Mark Wooding)
Re: Question about Re: RSA/PK Question (tomstd)
Re: Is it possible to use encryption to solve this problem? ("Trevor L. Jackson,
III")
Re: No-Key Encryption (John Savard)
----------------------------------------------------------------------------
Date: 2 Jun 2000 07:51:04 -0000
Crossposted-To: alt.security.pgp,alt.privacy,alt.privacy.anon-server
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
From: [EMAIL PROTECTED] (Nemo )
On Thu, 01 Jun 2000 20:48:52 +0100, EE Support
<[EMAIL PROTECTED]> wrote:
>I'm sorry to see this silly anti-Evidence Eliminator software messages
>continue.
If that is really true, then why are you "stoking the fires" by posting so
many replies to this thread?
--
Nemo -:- [EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Tableaus Revisited, Again
Date: Fri, 02 Jun 2000 10:46:52 +0200
"Douglas A. Gwyn" wrote:
> It is hardly fair to criticize historic innovations for not
> taking a more modern view. We would not have developed our
> more modern view without having gone through the historic
> process.
You are absolutely right. One is always more 'clever' when looking
back. The fact that cryptology was so tightly bound to 'secrecy' and
hence the interests of military and the state (diplomatic affairs) has
led to its more or less isolation up to the recent past from the public
spheres. Thus the development in cryptology had been comparatively
slow against other fields of natural sciences. This also explains why
decades ago there were once some thoughts to censor publication of
crypto articles in scientific journals. I am not sure that even today
certain authorities could feel entirely comfortable towards the massive
and rapid and international exchange of ideas of cryptology over the
internet, e.g. in our group. The world would certainly have been much
more 'in order' for them, had there been no such groupings of 'heretics'
that should properly be punished through being burnt alive.
M. K. Shen
===============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is it possible to use encryption to solve this problem?
Date: Fri, 02 Jun 2000 10:47:14 +0200
"S. T. L." wrote:
> more annoying. Copy protection is probably the last thing you should worry
> about. Making good software should be the first thing.
Yes. And provide good services and make the price cheap enough
(cheaper because of the consequently larger sales volume) to render
priacy not worthwhile and do some often (but not too frequent)
(eventuallly free) updates so as to bind the customers to you
permanently.
M. K. Shen
>
>
> -*---*-------
> S.T.L. Quotes page: http://quote.cjb.net Now playing: Half-Life
> "Never invest in something that violates a conservation law" - John Walker
> "If anyone wants a hole in the ground, nuclear explosives can make big holes" -
> Edward Teller
------------------------------
From: ahbeng <[EMAIL PROTECTED]>
Subject: Multiple exponentiation
Date: Fri, 02 Jun 2000 08:32:27 GMT
Using algorithm 14.88 (pp 618, Handbook of Applied Cryptography), a
multiple exponentiation of the form a^x b^y can be done in 1.2
exponentiation instead of 2.
My question is how to do the following?
a^x, a^x b^y
I been told that it can be done in 1.2 exponentiation instead of 2.2
exponentiation by deriving a^x from a^x b^y. I just can't figure out how
to do this. Can someone help me in this or point me to any papers that
describe how to do this.
Thanks in advance.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 02 Jun 2000 11:03:30 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: PKware (PKZIP) Encryption
[EMAIL PROTECTED] wrote:
>
> Does anyone know how well PKZIP encryption algorythem work? I have
> encrypted a file using this s/w and I am curious how safe it is
> provided that the password is long and random enough.
>
> Thank you all.
The PKZIP Encryption Algorithm was designed by Roger Schlafy.
According to "E. Biham, P.C. Kocher: A known plaintext attack
on the PKZIP Stream Cipher", K.U. Leuven Workshop on
Cryptographic Algorithms, Springer Verlag, 1995", it is broken.
Peter Conrad has written pkcrack, which breaks pkzip encrypted
files. That program is free for non-commercial use.
------------------------------
Date: Fri, 02 Jun 2000 11:05:03 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Can we say addicted?
wtshaw wrote:
> In article <[EMAIL PROTECTED]>, tomstd
> <[EMAIL PROTECTED]> wrote:
> > I am so addicted to this....
> You too? O, well, it's better than drugs, I suppose.
Hmm everything is better than drugs...
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Question about Re: RSA/PK Question
Date: 2 Jun 2000 09:28:38 GMT
DD <[EMAIL PROTECTED]> wrote:
> I don't understand what you mean, can you or anyone else please
> explain? Are you saying that it is not secure or that whether the
> key is 128bits or say 256 bits makes little difference in practice
> because both are thought to be secure today?
It probably really doesn't make much difference. Let's assume, for the
sake of argument, that Moore's Law will hold indefintely[1]. Assuming
that 2^64 is searchable now[2], we see that 2^128 is searchable in about
72 years time.
Here's the problem. While we can make dodgy extrapolations about how
well computer hardware will improve over the next 72 years, and at least
sound slightly plausible at the end of it, we can't predict how well
cryptanalytic techniques will improve in the same interval. Using
longer key lengths just makes this problem worse.
I suspect that the best we can do is to use a key length which will
delay brute force searches until we lose track of how well cryptanlysis
will be able to defeat the cipher. After that, increasing key length
really *is* useless.
The only option then remaining is to follow Terry Ritter's advice and
use compositions of many ciphers, in the hopes that even if the
individual components fail, the compositions will hold up. Composing
Serpent, Blowfish and Triple-DES seems like a reasonable place to
start.
[1] Not entirely unreasonable: the end of Moore's Law has been predicted
often, but I'm not holding my breath until it stops working.
[2] Deep Crack, a year or so old now, could search DES keys in a few
days. Take into account its age, and the fact that DES's key
schedule makes exhaustive search fairly easy, but also that it
wasn't very expensive, and add a factor of 2^8, and you end up with
about a year or so to search 2^64 with similar hardware. Now
assume, for the sake of paranoia, that there are organizations which
can do 2^16 times better than this, and we get 72 years out the far
end.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out po
Date: 2 Jun 2000 09:31:31 GMT
EE Support <[EMAIL PROTECTED]> wrote:
> On 31 May 2000 16:14:19 GMT, [EMAIL PROTECTED] (Mark Wooding) wrote:
> >There were no attacks on EE in sci.crypt. This thread is only in
> >sci.crypt because EE support spammed us.
>
> Sorry we don't SPAM.
I'm even sorrier that you do.
Discussion of your software is *off-topic* in sci.crypt. It is
irrelevant. sci.crypt is for the discussion of the science of
cryptography. Your software deletes stuff securely. I don't see a
connection there.
> We posted maybe 5 times to sci.crypt in the last year with
> announcements relating to discussions on our software in that group.
>
> Please prove us wrong.
I don't have to. You've just admitted sending unsolicited and off-
topic advertisements for your software to sci.crypt. I don't see what's
left to prove, to be honest.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: XTR (was: any public-key algorithm)
Date: 2 Jun 2000 10:27:19 GMT
David A. Wagner <[EMAIL PROTECTED]> wrote:
> I'd argue that the `standard' exponent is e = 3.
Well, SSLeay uses F_4 by default; Microsoft's cryptographic stuff uses
F_4 by default; nCipher[1]'s crypto accelerator boxes use F_4 by
default; SSH and PGP 2 use an odd number greater than 17.
I keep on reading that 3 is a commonly used exponent, but I've not found
a real system which actually uses it. ;-)
> (Yeah, e = 65537 might be more conservative, but if you're worried
> enough about speed to consider switching to a totally new
> cryptosystem, even e = 3 starts to look pretty good.)
This is true. However, there are problems if you send the same message
to e different people who all share the public exponent e, and a larger
e makes this less likely. There's also an attack due to Coppersmith
which can recover a message given two encryptions of it provided that
the random padding is less than 1/e^2 of the message length. Neither of
these is particularly worrying, I suppose, but there are more problems
which you need to think about when using small encryption exponents with
RSA.
[1] I work for nCipher, by the way. I don't think this matters much.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Contest rule proposal
Date: 2 Jun 2000 10:38:41 GMT
Andru Luvisi <[EMAIL PROTECTED]> wrote:
> I propose a rule that all algorithms for the sci.crypt crypto contest
> must be in the public domain. Please note, I am talking about the
> algorithms, and not the sample code.
I have a simpler proposal: require the code in the submissions to be
DFSG-free, i.e., free software within the meaning of the Debian Free
Software Guidelines (http://www.debian.org/social_contract#guidelines).
I believe that this will permit analysis and use of source code provided
with the submissions[1], and require the algorithms to be usable without
worrying about patents. I don't mind if the algorithms are patented as
long as that's not an encumbrance, and that there's a worldwide royalty-
free licence granted to use the invention.
And I'm certainly not wasting my time analysing algorithms which someone
wants to make money from.
[1] This is important. I want to be able to swipe bits of the example
source code to strap it into programs which perform differential
analyses, for example. Having to reimplement the cipher to do this
simple stuff isn't my idea of a good time.
-- [mdw]
------------------------------
Subject: Re: Powers of s-boxes and other functions
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 03:39:58 -0700
In article <[EMAIL PROTECTED]>, Jim Steuert
<[EMAIL PROTECTED]> wrote:
>Hi David,
>
> Thanks for your papers. I looked at them briefly. I will
study them,
>but I accept your results.
>
> I have been able compose permutation polynomials,
>and thus form powers.of a permutation (which must be
permutations).
>Note that we are iterating the whole function description. Only
after we
>iterate do we plug in a value. For powers of a permutation,
the plugged-in
>values can't collide. It all depends on what you consider the
inputs of the
>function.There are in fact two inputs: f(iteration count,root-
value). I'm
>not
>sure that collisions of the "count" would be a problem in some
applications.
>Plus,
>I think we can make the probability of such collisions
vanishingly small
>with some functions (I haven't shown this)
>
>My hope is that this we can find a large variety of functions
via symbolic
>algebraic methods. Several modern crypto functions have
algebraic
>description which may be useful for designing classes of these
functions.
Words of caution. Permutation polynomials form terrible sboxes.
Tom
* 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: Can we say addicted?
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 03:43:24 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
>In article <[EMAIL PROTECTED]>, tomstd
><[EMAIL PROTECTED]> wrote:
>
>> Hehehe I finished my bio work for the week so I decided to
make
>> another cipher...
>>
>...
>>
>> I am so addicted to this....
>>
>You too? O, well, it's better than drugs, I suppose.
No comments on either?
Hmm..
Tom
* 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] (Mark Wooding)
Subject: Re: No-Key Encryption
Date: 2 Jun 2000 11:08:14 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> What if we're using multiplication modulo 2^32, and we make sure that
> M is even (and thus not invertable)? If A and B are chosen to be odd,
> and greater than 1, they will have integer multiplicative inverses
> under the modulo, and can be removed by the host that knows them, but
> someone who wants to 'divide by' any multiple of M will be out of
> luck.
Divide by a multiple of M/2. You then have two possibilities to check
at the end rather than one. Big deal.
-- [mdw]
------------------------------
Date: Fri, 02 Jun 2000 07:21:32 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Question about Re: RSA/PK Question
tomstd wrote:
> In article <KkvZ4.15$[EMAIL PROTECTED]>, "DD"
> <[EMAIL PROTECTED]> wrote:
> >tomstd <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> In article <O04uc$3y$GA.187@cpmsnbbsa09>, "Joseph Ashwood"
> >> <[EMAIL PROTECTED]> wrote:
> >> >You and I both know that many of us (including myself) have
> >> >corrected you on this time and time again. If you are so
> >> >focused on only protecting against the right here right now,
> >> >why don't you use a 57 bit key? 56 bit's is the largest
> >> >that's been publically done, 64-bits has been going on for a
> >> >long time now, so 57 bits is good enough for now. Instead we
> >> >have as a community gone with AES at 128 bits minimum. You
> >> >seem to be very much the exception here, instead of the rule
> >> >you think you are.
> >> > Joe
> >>
> >> Although I should be doing my Bio I felt like reading the
> >> group. You are a pragmatic jerk, you know that right?
> >>
> >> I never said to use 57-bit symmetric keys. In fact I said to
> >> use 80-bits as the minimum for right now. I also said to use
> >> 768~1024 bit RSA keys because they can't be solved right now.
> >>
> >> I also don't agree with using 128+ bit symmetric keys because
> it
> >> provides a false sense of security. "Oh it's secure because I
> >> use a 256-bit symmetric key", big deal.
> >
> >I don't understand what you mean, can you or anyone else please
> >explain? Are you saying that it is not secure or that whether
> the
> >key is 128bits or say 256 bits makes little difference in
> practice
> >because both are thought to be secure today?
>
> I mean what I said, since you can't possibly search either a 128
> or 256 bit key space
now
> they are equally secure
now.
>
>
> When you compare 40 and 56 bit keys, well obviously 56 bit keys
> are more secure, since you can search both, just the latter
> takes more time.
>
> You can't search either 128/256 bit keyspaces
now
> , so technically
> there is no advantage to using 256 bit keys.
.. if the lifetime of the information you need to protect is small in comparison
to the time it takes to produce a breakthrough in in crypto technology. As a
thumb rule I'd use 1-10 years as the frame work for deciding between currently
effective key sizes (128 bits today) and "long term" keys sizes that must be
larger. Information that becomes useless in less than a year is probably safe
with keys sizes that are safe today, but info lifetimes above 10 years certainly
mandate a more generous margin of paranoia.
In the 1-10 year gray area one has to evaluate the cost-benefit tradeoff of more
than minimal security because finding quality implementations of more than
minimal security is difficult. Thus it sometimes becomes difficult to justify
the additional cost/effort/hassle of using larger keys.
While we may be able to create scalable security techniques such a cipher
stacks, and expandable cipher technologies, we don't seem to be able to produce
scalable cryptanalysis techniques. The fact that "the devil is in the details"
may indicate that scalable crypt analysis is probably a fantasy. Maybe there's
a niche for highly abstract AI products here?
------------------------------
Subject: Weak Keys in TC3
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 04:12:41 -0700
(TC3 is a block cipher I am working on. It's on my website)
I found the first class of weak keys...If the 6 key words are
all equal to -F(x+1), 0<x<7, then encrypting all zero makes an
all zero output. The prob of getting this key is 2^-192 and it
requires only one chosen plaintext to detect.
I think the attacks 'if a = c then' will work as well because
all you need is 'if (a + F(1)) == (c + F(4))) then' etc... which
means there are whole classes of bad keys.
Conclusion: The key schedule in TC3 is a poor design. Shame on
myself.
Any ideas on how to fix it? Should I use a fullblown key
schedule?
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Date: Fri, 02 Jun 2000 07:26:38 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Question about Re: RSA/PK Question
[EMAIL PROTECTED] wrote:
> In article <KkvZ4.15$[EMAIL PROTECTED]>,
> "DD" <[EMAIL PROTECTED]> wrote:
> > tomstd <[EMAIL PROTECTED]> wrote in message
> > > I also don't agree with using 128+ bit symmetric keys because it
> > > provides a false sense of security. "Oh it's secure because I
> > > use a 256-bit symmetric key", big deal.
> >
> > I don't understand what you mean, can you or anyone else please
> > explain? Are you saying that it is not secure or that whether the
> > key is 128bits or say 256 bits makes little difference in practice
> > because both are thought to be secure today?
>
> In an attempt to help Tom study bio, I will try putting words into his
> mouth. :)
>
> What I think Tom is getting at, is that a 256-bit key is as easy to
> bribe/steal/torture/blackmail out of users as a 128-bit key. However,
> since a 256 bit key is so much more secure in terms of brute-force
> check-all-keys attacks, people are more likely to commit secrets to
> 256-bit keys when the O(1) attacks on the keys are just as effective on
> 256-bit as 128-bit. The extra bits leads people to trust the system more
> than they should, leading to a false sense of security. (Or, perhaps, by
> seeing "256-bit" users might think the system is great, whereas the
> protocol itself might leak too much information, or the implementation
> was done poorly, etc..)
The same misinterpretations apply to 56/64-bit systems versus 128-bit
systems. Since the structure of your argument is independent of the numeric
values, it can't be used as a basis for conclusion about those numeric values.
Note that the argument is also independent of topic. It can be applied to
sound cards, disk controllers, and Microsoft(tm) operating "environments".
>
> (For those secrets where one needs 256-bits of brute-force protection, a
> good FIPS 140-1 level 4 hardware device with a threshold scheme on
> operators isn't too much to ask. :)
>
> But, of course, I don't speak for Tom -- I just think I understood what
> he was saying. :)
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Contest rule proposal
Date: Fri, 02 Jun 2000 13:27:07 +0200
Mark Wooding wrote:
> I have a simpler proposal: require the code in the submissions to be
> DFSG-free, i.e., free software within the meaning of the Debian Free
> Software Guidelines (http://www.debian.org/social_contract#guidelines).
>
> I believe that this will permit analysis and use of source code provided
> with the submissions[1], and require the algorithms to be usable without
> worrying about patents. I don't mind if the algorithms are patented as
> long as that's not an encumbrance, and that there's a worldwide royalty-
> free licence granted to use the invention.
Sorry for asking a dumb question. If a patent-holder gives a world-
wide royaltyfree license, why should he have spent money to obtain
the patent in the first place? Because it is simply fun and fashion
nowadays to be patent-holders, perhaps? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Contest rule proposal
Date: 2 Jun 2000 11:19:01 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Sorry for asking a dumb question. If a patent-holder gives a world-
> wide royaltyfree license, why should he have spent money to obtain
> the patent in the first place? Because it is simply fun and fashion
> nowadays to be patent-holders, perhaps? Thanks.
The simple answer: that's not my problem.
The more complicated answer: it only has to be the particular algorithm
which is free for DFSG-freeness; you can retain patent rights on
variants. Consider, for example, that the CAST design procedure is
patented, whereas CAST-128 and CAST-256 are both licensed worldwide
royalty-free and have been adopted as RFCs.
-- [mdw]
------------------------------
Subject: Re: Question about Re: RSA/PK Question
From: tomstd <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2000 04:27:59 -0700
In article <[EMAIL PROTECTED]>, "Trevor L. Jackson,
III" <[EMAIL PROTECTED]> wrote:
>tomstd wrote:
>
>> In article <KkvZ4.15$[EMAIL PROTECTED]>, "DD"
>> <[EMAIL PROTECTED]> wrote:
>> >tomstd <[EMAIL PROTECTED]> wrote in message
>> >news:[EMAIL PROTECTED]...
>> >> In article <O04uc$3y$GA.187@cpmsnbbsa09>, "Joseph Ashwood"
>> >> <[EMAIL PROTECTED]> wrote:
>> >> >You and I both know that many of us (including myself)
have
>> >> >corrected you on this time and time again. If you are so
>> >> >focused on only protecting against the right here right
now,
>> >> >why don't you use a 57 bit key? 56 bit's is the largest
>> >> >that's been publically done, 64-bits has been going on
for a
>> >> >long time now, so 57 bits is good enough for now. Instead
we
>> >> >have as a community gone with AES at 128 bits minimum. You
>> >> >seem to be very much the exception here, instead of the
rule
>> >> >you think you are.
>> >> > Joe
>> >>
>> >> Although I should be doing my Bio I felt like reading the
>> >> group. You are a pragmatic jerk, you know that right?
>> >>
>> >> I never said to use 57-bit symmetric keys. In fact I said
to
>> >> use 80-bits as the minimum for right now. I also said to
use
>> >> 768~1024 bit RSA keys because they can't be solved right
now.
>> >>
>> >> I also don't agree with using 128+ bit symmetric keys
because
>> it
>> >> provides a false sense of security. "Oh it's secure
because I
>> >> use a 256-bit symmetric key", big deal.
>> >
>> >I don't understand what you mean, can you or anyone else
please
>> >explain? Are you saying that it is not secure or that
whether
>> the
>> >key is 128bits or say 256 bits makes little difference in
>> practice
>> >because both are thought to be secure today?
>>
>> I mean what I said, since you can't possibly search either a
128
>> or 256 bit key space
>
>now
>
>> they are equally secure
>
>now.
I seriously doubt 256-bit keyspaces will be exuasted any time
soon. Even if QC becomes a reality (which it will) then you are
looking at 2^128 time which is still big. As it stands no
digital computer (or combination thereof) can exhaust even a 80-
bit keyspace now, so I would strongly suggest 128-bit being non-
searchable. Sure 100 years from now 80-bit keys may be trivial
(same for 128) but now. And most secrets are only secrets for
at most 5 years anyways...Who cares what your secret recipe for
crispy chicken is 10 years from now?
>>
>> When you compare 40 and 56 bit keys, well obviously 56 bit
keys
>> are more secure, since you can search both, just the latter
>> takes more time.
>>
>> You can't search either 128/256 bit keyspaces
>
>now
Or for a very long time.
>
>> , so technically
>> there is no advantage to using 256 bit keys.
>
>... if the lifetime of the information you need to protect is
small in comparison
>to the time it takes to produce a breakthrough in in crypto
technology. As a
>thumb rule I'd use 1-10 years as the frame work for deciding
between currently
>effective key sizes (128 bits today) and "long term" keys sizes
that must be
>larger. Information that becomes useless in less than a year
is probably safe
>with keys sizes that are safe today, but info lifetimes above
10 years certainly
>mandate a more generous margin of paranoia.
>
>In the 1-10 year gray area one has to evaluate the cost-benefit
tradeoff of more
>than minimal security because finding quality implementations
of more than
>minimal security is difficult. Thus it sometimes becomes
difficult to justify
>the additional cost/effort/hassle of using larger keys.
>
>While we may be able to create scalable security techniques
such a cipher
>stacks, and expandable cipher technologies, we don't seem to be
able to produce
>scalable cryptanalysis techniques. The fact that "the devil is
in the details"
>may indicate that scalable crypt analysis is probably a
fantasy. Maybe there's
>a niche for highly abstract AI products here?
Suggesting people to use 256-bit keys as they are more secure
now is irresponsible. Heck as I stated 80-bit keys are secure
now.
Let's say a 64-bit key would take a year with distribute.net
(now). If moores law continues for 10 years, we will see a 6.5x
fold in compute speed, still not enough to search a 80-bit key
in reasonable time. It would take 10,082 (compared to 56 days
with the 64-bit key) years to search. Let's say 50 years (33.3x
speed) the same 64 bit key will take about 11 days to find, but
a 80-bit key requires about 1,968 years still. Let's say moores
law contiunes for 100 years, and the # of computers quadruples
we will see a 266.6x speedup. A 64-bit key could be found in
1.36 days, and the same 80-bit key takes 245 years.
Now saying computers will grow 4x in numbers is not realistic.
I think after 100 years we will see a 100x increase in
computers, note this is a 6144x speedup. A 64-bit key would
take about 0.059 days (1h 25m) to find, and a 80-bit key would
take 10.6 years.
So even if the # of computers increases by 1x each year and the
computing speed doubles every 18 months, a 80-bit key will be
secure 100 years from now for about 10 years. I think this is
fairly resonable since I can't expect to see the number of
usable computers go up exponentially each <specific time period>
No I am not saying to go out of your way to use 80-bit keys over
128-bit keys, but don't let paranoia get in the way of good
judgement.
Food for thought,
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Date: Fri, 02 Jun 2000 07:41:21 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Is it possible to use encryption to solve this problem?
Thierry Moreau wrote:
> As of today, the SAKEM registration procedure is available as a license to
> use a patented procedure plus "portable" C++ implementation. The
> cryptographic aspects of the rest of the plan (encryption per (3) and
> chellenge-response protocol per (4)) is a relatively small development
> task.
"small develpment task" compared to what?
While the amount of _code_ may be small, the amount of effort required is not
small.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: No-Key Encryption
Date: Fri, 02 Jun 2000 11:11:19 GMT
On Thu, 01 Jun 2000 19:17:01 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>Perhaps there is a misunderstanding between us. My point was
>that imposing the requirement 'M*A*B=M*B*A for any M,A,B'
>IS imposing the requirement of commutativity of the operator '*'.
Is it? I couldn't prove it. Obviously A*B must be closely related to
B*A if M* either of them is the same...but that doesn't mean they have
to be equal.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
** 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
******************************
