Cryptography-Digest Digest #52, Volume #10 Sun, 15 Aug 99 15:13:03 EDT
Contents:
Re: Cracking the Scott cryptosystems? (SCOTT19U.ZIP_GUY)
Re: NIST AES FInalists are.... ("Douglas A. Gwyn")
Re: New encryption algorithm ("Douglas A. Gwyn")
Re: New encryption algorithm ([EMAIL PROTECTED])
CRYPTO DESIGN MY VIEW (SCOTT19U.ZIP_GUY)
Re: NIST AES FInalists are.... (David Wagner)
Re: NIST AES FInalists are.... (David Wagner)
Re: The Most Secure Symmetric Algorithm (not counting the one-time pad) Ever!
Re: NIST AES FInalists are.... (David Wagner)
Re: Wrapped PCBC mode ([EMAIL PROTECTED])
Re: NIST AES FInalists are.... (David Wagner)
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
chat sessions? ([EMAIL PROTECTED])
Re: Wrapped PCBC mode (SCOTT19U.ZIP_GUY)
Re: Cracking the Scott cryptosystems? ([EMAIL PROTECTED])
Re: chat sessions? (Ruud de Rooij)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Cracking the Scott cryptosystems?
Date: Sun, 15 Aug 1999 17:29:39 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>> Actually DES or any random generator show a likeness to a OTP
>> if used properly and for ONE TIME since any sequence could in theroy
>> have come from a OTP it is just that when the source used for the pad
>> is known then analysis can say that it is not a valid source for use
>> with a OTP.
>
>I'm not sure what you meant by the last part there, but the first
>part shows a profound misunderstanding -- as enterrottacher hinted,
>use of DES as the encryption system imposes a tight set of
>constraints that makes it quite feasible to recover even a single
>message with a key used just once, with virtual certainty about
>the result (witness the EFF DES cracker). That is nothing like a
>OTP system. The fact that the ciphertext is a possible output
>from some unrelated OTP system has nothing to do with the DES
>encryption itself.
It is clear you don't understanf what i mean that is OK i do think
DES is weak but to clarify my thougths I wrote a short post
CRYPTO DESIGN MY VIEW
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Sun, 15 Aug 1999 16:06:42 GMT
[EMAIL PROTECTED] wrote:
> Well if all keys are equal then the fastest brute force method is ...
Ah -- I didn't catch from the original message that you meant only
among exhaustive key-space search methods. Yes, obviously those
are faster if parallelized, and they can be effectively parallelized
since each key test is independent (since you're assuming no
cleverness is used). If analysis can show a qay to perform one key
test using partial results from an adjacent key test, then even a
sequential search could be sped up.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New encryption algorithm
Date: Sun, 15 Aug 1999 16:26:15 GMT
[EMAIL PROTECTED] wrote:
> (lol ... I am being sarcastic).
> Hey Dave, why not just shut up.
You're repeating yourself, and it doesn't seem to have much effect
other than to add to the overall noise level. Try addressing his
actual arguments, which would add to the enlightenment level.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New encryption algorithm
Date: Sun, 15 Aug 1999 16:09:12 GMT
In article <7p6kj1$36h6$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Actual this is not true. IF it really is revolutionary and out if
the main
> stream. You would never get it published in a journal since you are an
> outsider. Oh they might do it if it is weak so they can poke fun at
it,
> But it would never see the light of day if it was good and not
previously
> blessed by a crypto god. About the only way it will get published is
when
> one of them highly respected people steals your method.
That's right, only people like you can make good algorithms. I forgot
you are perfect.
(lol ... I am being sarcastic).
Hey Dave, why not just shut up. Your funny to read once n' a while but
really you are pushing it. You make all these claims (AES is weak, NSA
is out to get me, I am smart) and never EVEN TRY to prove it. Why not
prove at least one of your wild claims and redeem yourself. Or are you
just a bag-of-wind?
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: CRYPTO DESIGN MY VIEW
Date: Sun, 15 Aug 1999 17:32:59 GMT
This is my real world view of crypto and why I design
things the way I do. In the real world no one knows
how good groups like the NSA are since the chinese don't
tell us what methods they use we can't know. But there
is something we can do. We can design code from a
reachable information point of view. Thus we can in
many cases tell how much encrypted text an agency needs
to look at in order to have enough information to break
the system. Note this does not mean that they have
broken the system only that there is enough information
to break it.
Example one I send a message in IDEA using any one
of the standard blessed chaining methods. Suppose they
know that the words "Kill all the Cats" is somewhere in the
middle of the message. If they test any key on a portion
of the encrypted file that has a 2 block buffer so
the error recovery effect that is so masterfully used
with most ciphers how many keys would come up with this
exact text. Well it depends on many things including
the lenght of key used. but since the key is 128 bits
long and the known text is 17*8 or 136 bits long there
is likely only one key that matches this. So in this
fragment of file that is being examined the whole amount
of information of the soultion is there. Note since one
is not exactly sure of the character where the message
started one would have to look at a few different
possible start locations.
Next suppose one got a little brighter and used
Huffman compression with a fixed table. Know the
known text is smaller so that a longer fragment
would be needed to supply enough information to
break the code. But since static huffman was used
that sequence of compressed code is known it is fixed
but you still add the complicaton that since compressed
there are eight times as many starting locations
as to where the string started. Next suppose the guy
is a little brighter and used my "adaptive huffman
compression" know the attacker has no idea of what
the compressed string looks like and the amount of
information required for even a theoritically solution
is far less. So from an information point of view
alone it would be far wiser to use the adaptive
huffman compression. This in itself does not help
if the known fragment of the message is at the
start of the message itself. To get around that
problem it would be best to use "wrapped PCBC" or
to use another adaptive huffman compression in the
reverse direction so that the "all or nothing"
effect is taking place. Something the BS crypto
gods do not want you to do.
I happen to have code for all this at
http://members.xoom.com/ecil/compress.htm
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST AES FInalists are....
Date: 15 Aug 1999 09:30:05 -0700
In article <7p6n70$fi5$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> If we are prepared to imagine a real world protocol that decrypts 2^36
> chosen blocks (a thousand Gigabytes) with the same key we should also
> be prepared to imagine a protocol that leaks the key as plaintext.
Well, I see your point, but as network speeds increase, in the future
obtaining 2^36 blocks may not be so unthinkable as you imagine.
In particular, my understanding is that the whole reason NIST asked for
a 128-bit blocksize is because they anticipate that some people will want
to use the cipher for more than 2^32 blocks, and ciphers with a 64-bit
block are vulnerable to birthday weaknesses after 2^32 blocks in most
modes of operation.
So, if you believe NIST, it is at least somewhat important to ensure
security past 2^32 blocks of data.
> Schneier's group attack on Frog is significant in the sense that it
> uncovers a fact about variable ciphers such as Frog: that some of the
> cipher instances will necessarily be "weaker" than others.
I'd agree with this assessment whole-heartedly. This type of observation
is probably much more important than any theoretical chosen-plaintext attack.
> A few of the keys of a Frog-like cipher will be weak, but the
> variable nature of this cipher makes it very unlikely that an attack
> will be discovered for which all or a large fraction of the keys will
> be weak. On the other hand, with a conventional "fixed wire" cipher it
> is much more probable that an attack exists that works against all the
> keys.
I'd claim that if your cipher allows for 2^20 wirings, that should
probably be viewed as 2^20 ciphers which must all be validated. Unless
you do something clever, analyzing a set of 2^20 wirings will always be
harder than analyzing one wiring. Given the tight AES timeline, the
limited cryptanalytic resources, and the unknown competence of the
academic world at designing very high assurance block ciphers, it might
not be a good idea to add to the evaluation burden in this way.
Keyed wiring may reduce the risk of a catastrophic compromise, but it
also seems to increase the cost of evaluation and validation. It's a
tradeoff, IMHO.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST AES FInalists are....
Date: 15 Aug 1999 10:02:34 -0700
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> Under assumptions which,
> admittedly, were generous (assume no cost to make the machine flexible,
> rather than fixed-purpose, assume the NSA has technologies 100 times more
> efficient, assume the NSA can spend $25 billion as opposed to the $250,000
> spent by the EFF, assume they can tie the machine up for 6 months or so on
> a single problem) I noted that the success of the DES cracker implied that
> even 80-bit keys could be within the reach of the NSA.
Er, even the first three assumptions suffice to conclude that 80-bit keys
are within reach, within days. No need to tie up the machine for 6 months.
100x efficiency gain => 7 bits
$25 billion / $250k => 17 bits
56+7+17 = 80
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: The Most Secure Symmetric Algorithm (not counting the one-time pad) Ever!
Date: 15 Aug 99 17:02:21 GMT
John Savard ([EMAIL PROTECTED]) wrote:
: My "Large-Key Brainstorm", on the bottom of the page
: http://www.ecn.ab.ca/~jsavard/co0412.htm
: has now had a modified version added which, instead of encrypting a
: whole eight bytes at each iteration, only encrypts one byte at a time
: - allowing convenient stream cipher use.
This particular cryptographic flight of fancy has now been moved to
http://www.ecn.ab.ca/~jsavard/co041205.htm
as part of a reorganization in which the various extravagant examples
appearing in the conclusions sections of the rotor machine and computer
era chapters have now been put into subsections of their own, thus
speeding the time to load each individual HTML page.
I also took my modification of Joan Daemen's Panama and took it off the
section describing Panama itself and placed it in this area as well (at
co041201.htm).
John Savard
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST AES FInalists are....
Date: 15 Aug 1999 10:18:35 -0700
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> (a) I assume by "superb cryptologists" you mean the people who
> contributed AES candidates, participated in AES conferences, etc.
> It is to be expected that they would highly "rate" cryptosystems
> similar to the ones they themselves design, regardless of whether
> or not the systems are really secure. What would be reassuring
> would be for *demonstrably superb cryptanalysts* to have attacked
> the AES candidates and have rated them according to their
> withstanding the attacks. But few if any of the evaluators
> appear to have ever successfully cryptanalyzed *any* difficult
> real-world cryptosystem, so what use are their ratings, anyhow?
I thought about this argument for a while, and at first glance there
seems to be something slightly fishy about it.
Reviewing the published examples of successful cryptanalysis of real-world
cryptosystems (Kerberos, SSL, SSH, IPSEC) shows that most breaks don't
exploit the internal mathematics of the block cipher. Most breaks exploit
properties of modes of operations, poor randomness, protocol failures,
bad interactions with other system components, use of the wrong type of
primitives, etc. But very few real-world breaks actually do any block
cipher cryptanalysis.
If we assume for the moment that this published experience is
representative, this suggests that the way to break real-world systems
is not to study block cipher cryptanalysis but instead to study systems
issues.
Thus, I see no reason to believe that the folks with a proven track
record at breaking real systems will be especially good at analyzing
block ciphers.
I'm sure I must be missing something. (Maybe my assumption is wrong,
or I'm just too young to have the necessary accumulated wisdom.)
Would you mind helping me to understand your reasoning?
Maybe it would help if you gave an example or two of a difficult
real-world cryptosystem that has been successfully cryptanalyzed in
the public sector, so I could understand how you use those terms?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Wrapped PCBC mode
Date: Sun, 15 Aug 1999 19:09:29 +0200
[EMAIL PROTECTED] wrote:
>
> Can someone name me one benefit of Dave's 'super-duper' W-PCBC mode?
A brute-force-attack needs slightly more time since one has to decrypt
the whole message to find out whether the key produces garbage or not.
The factor is
(number of blocks) * (number of 'wraps')
So for a message with 2^6 blocks and with 4 encryptions (4 'wraps')
you'll win 8 bit of strength against brute-force-attacks.
If you are using the same key for all 'wraps' you might introduce a
weakness in your system, but if you are using a different key for each
one the system should be at least as strong as multiple encryption in
one of the standard modes.
For error detection CBCC would be enough.
Enterrottacher Andreas
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST AES FInalists are....
Date: 15 Aug 1999 09:53:41 -0700
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> What has never been explained is the technical design that
> could allow such a cipher to be exploitable by the Agency
> but not by our enemies.
I think it _has_ been explained.
See Rijmen and Preneel's work on "trapdoor ciphers" for an example of
a plausible design that seems to allow a designer to embed a secret
trapdoor in a block cipher. Revealing the specification of the cipher
apparently does not reveal the trapdoor.
I suspect that this design task might be very challenging. Still,
you've been arguing that the NSA is quite a bit better at cryptanalysis
and design than the academic community; if we are to believe this, I
think it is not unreasonable to believe that it is entirely plausible
that the NSA might be able to build a cipher with a practical trapdoor
that remains secret even after the cipher is published.
(The details of Rijmen and Preneel's concrete proposal are broken, but
the basic approach seems potentially sound, and I believe the details
can be fixed. I'll give more details if you like; I haven't seen my
proposed fixes published anywhere.)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Sun, 15 Aug 1999 17:18:35 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Well if all keys are equal then the fastest brute force method
is ...
>
> Ah -- I didn't catch from the original message that you meant only
> among exhaustive key-space search methods. Yes, obviously those
> are faster if parallelized, and they can be effectively parallelized
> since each key test is independent (since you're assuming no
> cleverness is used). If analysis can show a qay to perform one key
> test using partial results from an adjacent key test, then even a
> sequential search could be sped up.
>
He was talking about 'NSA super brute force methods' and my point was
they dont call it 'brute force' because it's easy. 99% of the time
brute force is the easiest (or only way) method to attack a message.
You can get faster computers and more of them, but you still have to
perform a linear search. There are no 'NSA' tricks here.
Even still there are limits. He honestly believes 80/128 bit keys are
in the realm of searchable. (probably because he can't count).
Oh well.
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Sun, 15 Aug 1999 17:51:10 GMT
In article <7p6pud$1u4$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> In article <7p6n70$fi5$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
wrote:
> > If we are prepared to imagine a real world protocol that decrypts
2^36
> > chosen blocks (a thousand Gigabytes) with the same key we should
also
> > be prepared to imagine a protocol that leaks the key as plaintext.
>
> Well, I see your point, but as network speeds increase, in the future
> obtaining 2^36 blocks may not be so unthinkable as you imagine.
However in most cases it's not possible. If I send a PGP message to
you for example you get say 100 blocks of ciphertext. Not enough for
any real cipher. Though some networks (as you said) might be sending
quite a bit of data...
> In particular, my understanding is that the whole reason NIST asked
for
> a 128-bit blocksize is because they anticipate that some people will
want
> to use the cipher for more than 2^32 blocks, and ciphers with a 64-bit
> block are vulnerable to birthday weaknesses after 2^32 blocks in most
> modes of operation.
>
> So, if you believe NIST, it is at least somewhat important to ensure
> security past 2^32 blocks of data.
Good point. Also with a bigger block length you get higher thru-put
and bigger sub-groups (when using CBC/CFB modes) (if any, I doubt that
all ciphers for all keys form single cycle substitutions for all
possible plaintext).
> I'd claim that if your cipher allows for 2^20 wirings, that should
> probably be viewed as 2^20 ciphers which must all be validated.
Unless
> you do something clever, analyzing a set of 2^20 wirings will always
be
> harder than analyzing one wiring. Given the tight AES timeline, the
> limited cryptanalytic resources, and the unknown competence of the
> academic world at designing very high assurance block ciphers, it
might
> not be a good idea to add to the evaluation burden in this way.
>
> Keyed wiring may reduce the risk of a catastrophic compromise, but it
> also seems to increase the cost of evaluation and validation. It's a
> tradeoff, IMHO.
A tradeoff your team made. You have keyed sboxes in your cipher, so
does Blowfish, ICE has keyed bit permutations ... etc...
You can mix keyed parts of the cipher with structured parts. I think
keyed constructions can be strong if used properly.
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: chat sessions?
Date: Sun, 15 Aug 1999 17:39:42 GMT
I was thinking in order to promote more discussion why not have live
chat sessions for the group? We can discuss things more rapidly then
thru newsgroups ...
How about 8PM (-5:00 GMT) every sunday on EFnet in the group 'scicrypt'.
I will be using the server 'irc.idirect.ca' if anyone is interested.
Everyone is invited, and there are no real topics. We will just find
something to talk about. And please no flaming people or other groups.
It's in 6.5 hours from now hopefully one or two can show up. Hopefully
next week more...
cya there,
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Wrapped PCBC mode
Date: Sun, 15 Aug 1999 19:12:43 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] wrote:
>>
>> Can someone name me one benefit of Dave's 'super-duper' W-PCBC mode?
>
>A brute-force-attack needs slightly more time since one has to decrypt
>the whole message to find out whether the key produces garbage or not.
>The factor is
>
> (number of blocks) * (number of 'wraps')
>
>So for a message with 2^6 blocks and with 4 encryptions (4 'wraps')
>you'll win 8 bit of strength against brute-force-attacks.
>
Actually you gain far more than that. Since all of the blessed chaining
modes only require a few blocks at most to be analyzed your need to
look at fewer than a dozen such blocks. Even the NSA is not so stupid
that it would look at a whole file for a blind seaerch of a key when a
small easy to search segment is all that is needed. Plus if your using
special asynchrous digital custom machines it is far easy and less hardware
intensive to just use a small fragment of the file. This task is much harder
with "wrapped PCBC".
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cracking the Scott cryptosystems?
Date: Sun, 15 Aug 1999 20:32:56 +0200
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> >SCOTT19U.ZIP_GUY wrote:
> >> ...
> >> It seems to me that all good crypto systems should act like
> >> a OTP if a different key is used for "EACH MESSAGE" since
> >> it is the only provable secure method. WAKE UP
> >
> >I don't think this behaviour tells anything about the strength of the
> >system:
> Yout corrent put the presious post implied a weakness by assocaition
> to the OTP
>
> >
> >1) A vernam cipher behaves like an OTP as long as the key is longer than
> > the message but it can simply be broken for longer messages.
> >
> >2) DES doesn't show this behaviour even for a single block since it
> > generates only 2^56 of the possible 2^64 permutations, but for longer
> > messages it is much stronger than a vernam cipher.
> Actually DES or any random generator show a likeness to a OTP
> if used properly and for ONE TIME since any sequence could in theroy
> have come from a OTP it is just that when the source used for the pad is
> known then analysis can say that it is not a valid source for use with a
> OTP.
I disagree: Think about an encrypted message generated with an unknown
cipher. The attacker tries the most common blockciphers and finds that
one DES-key allows to generate plaintext that looks good.
The probability to get this result by using this method on an OTP is
very small:
Since the entropy in english text is about 2 bit per character the
probability to get something else than rubbish by producing random
numbers by deciphering the OTP-encrypted message with DES is about
(2^-6) ^ (number of characters)
per tested DES-key. For all messages with more than 10 characters the
probability is smaller than one if all DES-keys are tested.
For a message of only 1 kbyte (less than 20 lines of this message) the
probability to get such a text is about 2^-6000. This should allow to
distinguish between any known cipher and an OTP.
>
> >
> >If you want to use a OTP - why not?
> >But for a cipher that should be used daily I'd prefer one with the
> >properties of a modern blockcipher:
> By properties of a modern block I assusme mean things like
> the error recovery.
Good example :)
> But I prefer the features that should be found
> on future ciphers for files. Namely a one bit change in input cahnges
> the whole file out.
What's the use of it?
It should be enough to add a checksum to find the error.
> One where the entropy of message is spread
> a lot better than the AES small black cipher with tiny keys.
Why?
> ...
> Actually I prefer using pass pharse that are easy to rember too
But what is the use of a huge key that contains only a small amount of
entropy?
> ...
> The design methods of the AES
> candidates means they can't be good for file or serious message
> protection.
Why do you think so?
All AES candidates were developed to withstand all known attacks.
All of them are using more rounds than neccessary and the developers
tried to add as much security as possible against unknown attacks (the
unkeyed rounds in MARS, for example).
All of them allow to use a key that is even with the smallest keysize
large enough to protect secrets for a very long time.
> Only an idiot would say "The key should be just long enough to
> keep the attacker from trying brute-force-attacks" ...
What else is the use of keylength?
Of course the neccessary length will depend on the expected attacker
and on the time the cipher has to be strong.
For my personal mail algorithms like 3way or skipjack are by far enough
(even DES would be enough :), but for banking I'd prefer 3DES and to use
a system that generates random keys - they are more important than
several hundered bits of keylength derived from a simple password.
If the security of a nation depends on the strength of a cipher I'd
prefer OTPs since they are PROVABLY secure.
But what is the use of the huge key of SCOTTxxx?
One could use it like a normal cipher and this way use only a password
with a small amount of entropy - in this case he could as well use a
blockcipher.
Or he could use a key about the same size as the message -
in this case it would be better to use OTPs since they are provably
secure while nobody knows if there are flaws in SCOTTxxx.
I think this is the reason why SCOTTxxx is not generally used: On the
one side it is not as comfortable as a modern blockcipher, on the other
side it is not provably secure like OTPs.
Most ciphers are used transparently - automatic encryption in networks,
email encryption , archiver with encryption option etc.
I don't think SCOTTxxx would be a good choice for transparent file or
message encryption.
On the other hand if security is more important than everything else the
OTP will be the best choice and not even SCOTTxxx could deliver this
amount of security.
Enterrottacher Andreas
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: Ruud de Rooij <*@spam.ruud.org>
Subject: Re: chat sessions?
Date: 15 Aug 1999 20:08:56 +0200
Reply-To: *@spam.ruud.org
[EMAIL PROTECTED] writes:
> I was thinking in order to promote more discussion why not have live
> chat sessions for the group? We can discuss things more rapidly then
> thru newsgroups ...
>
> How about 8PM (-5:00 GMT) every sunday on EFnet in the group 'scicrypt'.
>
> I will be using the server 'irc.idirect.ca' if anyone is interested.
>
> Everyone is invited, and there are no real topics. We will just find
> something to talk about. And please no flaming people or other groups.
>
> It's in 6.5 hours from now hopefully one or two can show up. Hopefully
> next week more...
For next time, could you consider a time that is somewhat more
friendly to Europeans. Monday morning 3am is not exactly convenient :-)
- Ruud de Rooij.
--
ruud de rooij | *@spam.ruud.org | http://ruud.org
------------------------------
** 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
******************************
