Cryptography-Digest Digest #104, Volume #10 Tue, 24 Aug 99 16:13:03 EDT
Contents:
Re: What the hell good is a session key! (Volker Hetzer)
Re: Entropy in "modified" passwords (Anton Stiglic)
Re: crypto survey (Anton Stiglic)
Re: CRYPTO DESIGN MY VIEW (Mok-Kong Shen)
Re: What the hell good is a session key! (Eric Lee Green)
cryptographic DLL (Tom St Denis)
Re: How does RC4 work ? (Paul Crowley)
Re: Attacks on RC4 ? (Paul Crowley)
Re: How Easy Can Terrorists Get Strong Encrypt? (Paul Koning)
Re: What the hell good is a session key! (jay)
Re: What the hell good is a session key! (jay)
Re: One-time pad encryption. (Paul Koning)
Help: DES Encryption -> ASCII ([EMAIL PROTECTED])
Re: One-time pad encryption. (fungus)
Re: DES key parity! (Paul Koning)
Re: Updated paper on ECDSA (DJohn37050)
Re: What the hell good is a session key! (Anton Stiglic)
Re: simple message encryptor for ICQ like programs (Michael J. Fromberger)
Re: What the hell good is a session key! (Anton Stiglic)
Re: What the hell good is a session key! (Eric Lee Green)
Re: What the hell good is a session key! (Anton Stiglic)
----------------------------------------------------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: What the hell good is a session key!
Date: Tue, 24 Aug 1999 17:12:42 +0200
Anonymous wrote:
> Conclusion: if an attacker can do a brute-force for one key, if your only
> protection is that they would need to brute-force two keys, or need more
> than one block, you need to worry some.
There are several advantage to session key schemes:
- The master cipher can be slow (long key).
- Very few bytes get encrypted using the master key, therefore giving
the cryptanalyst less material to work with.
- Recovery of the master key does not necessarily lead to the recovery
of each session key.
So, in a non-session-key protocol, getting hold of the key gives you access
to any message, past and future.
In a good session-key protocol, getting hold of the master key gives you access
at most to future messages. Every past message requires a separate break.
If this means a month per message then your algorithm is crap. However,
if you want to protect each individual message for one month, then a long
master key and a short session key is the perfect solution.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Entropy in "modified" passwords
Date: Tue, 24 Aug 1999 12:16:38 -0400
I have posted the definition of entropy in a previous post:
the definition of Entropy Anton Stiglic 07/28/99 13:06 sci.crypt
It might be helpfull...
Anton
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: crypto survey
Date: Tue, 24 Aug 1999 12:22:10 -0400
It is _always_ Oscar. :)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Tue, 24 Aug 1999 18:24:17 +0200
SCOTT19U.ZIP_GUY wrote:
> I hope you can get it this time
> the xxxxxxxx xxxxxxxy yyyyyyy is a valid bit stream that will be written as
> xxxxxxxx xxxxxxxy yyyyyyy for the case you used
>
> xxxxxxxx xxxxxxx_ is a valid bit stream that can lead to
> xxxxxxxx xxxxxxx0 for most cases this is finally compress file
>
> xxxxxxxx xxxxxxx_ is a valid bit stream let 8 1's be last token
> xxxxxxx1 is a valid compressed file for this case
>
> Another example in your format
> xxxxxxxx xxx_____ this is valid huffman stream suppose 10 last token
> xxxxxxxx x1000000 this is compressed file out for this case
>
> xxxxxxxx xxx_____ in this case asumme 10111 last token out
> xxxxxx10 this compressed file out.
Evidently I haven't yet succeeded to fully convey my ideas to you
(no blame tp you but rather to me myself). Let me try to formulate
my question more simply:
Suppose the input file is
......abcq
and it gets compressed to a file as follows (the dots in the two
cases don't have the same meaning):
......... xxxxxxxx xxxxxxx0 10110010
and we know that 0 10110010 is the Huffman code of q. So this file
decompresses back to
......abcq
Am I right?? Now what does a file with (the last byte above is removed)
......... xxxxxxxx xxxxxxx0
decompress to?? Which one of the following possible cases holds?
(1) ......abc is the decompression result, with no error message.
(2) ......abc is the decompression result, with an error message.
(3) The program simply aborts.
(4) Others. (Please detail in this case.)
Thank you in advance.
M. K. Shen
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: What the hell good is a session key!
Date: Tue, 24 Aug 1999 09:23:47 -0700
Anton Stiglic wrote:
> In the project I'm working at, master key is RSA-2048 bit, session
> keys (that last about a month), is 1024 bit. We also have different levels
> of master keys,
Hmm. I thought the whole point of master keys was that they were for an
asymetric algorithm used to transfer session keys for a symmetric
algorithm, symetric encryption being much harder to crack and
mathematically more secure than asymetric algorithm for any given key
length, meaning shorter keys (more performance) can be used for the
actual grunt work of the session, and meaning less ciphertext exposed
for analysis for any given key.
I suppose the idea of exposing as little ciphertext to analysis as
possible is an idea, and a "master" key could be used to "re-key the
world" every month (the way you seem to be doing), but using a shorter
key length for "the world" does not strike me as a good idea. Given that
even many cryptographers are uncomfortable with the idea of RSA as
unbreakable (I think it was Schneier who said that he feared that some
quantum leap in mathematical knowledge would render RSA worthless), and
given that the primary use of these keys will be to transfer the session
keys for the symmetric encryption that is doing the "heavy lifting", it
does not strike me that performance justifies the loss of mathematical
strength here. Even 2048-bit RSA has less mathematical strength than any
of the AES candidates at 128-bit key length, after all.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: cryptographic DLL
Date: Tue, 24 Aug 1999 16:25:09 GMT
I packaged the Twofish/Blowfish/Sha code from PeekBoo into a DLL that
every can use with an easy API. Check it out at
http://people.goplay.com/tomstdenis/cdll.zip
It's for x86 win32 only (which is 95% of all computers). It's free,
small and relatively fast. Enjoy :) (includes binaries and source)
Another plug, if you want to check out my free message
encryptor/decryptor for win32 (for use with programs like ICQ, IRC, and
email) check out
http://people.goplay.com/tomstdenis/pb.html
Thanks for your time and remember, both are free, this is not a spam,
both include source, they are not 'closed door' apps. And I am open to
suggestions/improvements!!!
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: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: How does RC4 work ?
Date: 24 Aug 1999 10:16:30 +0100
Tom St Denis <[EMAIL PROTECTED]> writes:
> > http://ciphersaber.gurus.com
>
> No offense but is that a plug?
The point about CipherSaber is that there are no implementations on
the home page - you're supposed to code your own. My only connection
with CS is that I qualify as a KryptoKnight since I have coded my own
implementation of it (actually two implementations) and decrypted my
certificate.
> RC4 is so simple you could explain it here no need to advertise.
Hey, I provided complete source, what more do you want?
Encryption:
./ciphersaber 0 PassPhrase < plain.txt > cipher.cs1
Decryption:
./ciphersaber 1 PassPhrase < cipher.cs1 > plain.txt
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Attacks on RC4 ?
Date: 24 Aug 1999 10:26:09 +0100
Tom St Denis <[EMAIL PROTECTED]> writes:
> In article <[EMAIL PROTECTED]>,
> Paul Crowley <[EMAIL PROTECTED]> wrote:
> > I'm sure others here will supply details of the two weak key attacks
> > found by Andrew Roos and David Wagner, but here's the one other
> result
> > I know about: a very tiny bias in the CPRNG, experimentally verified.
> >
> > http://www.hedonism.demon.co.uk/paul/rc4/
>
> Here is my question. What machine did you test 2^45.5 bytes on?
> That's about 50 days of work or so... Do you have more info on it?
It's more like 100 days on the slow machines I was using: my 2
processor machine at work and my very slow home machine. I just set
it going whenever the machine was going to be idle.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: How Easy Can Terrorists Get Strong Encrypt?
Date: Tue, 24 Aug 1999 12:42:26 -0400
Greg wrote:
>
> In case anyone is interested, this came from WND...
>
> Indeed, a recent study by the George Washington University School of
> Engineering and Applied Science backs up Goodlatte. It found good
> encryption programs available outside the United States on more than
> 800 Websites.
That's only part of the answer to the question in your subject string.
The other part: anyone with enough programming skill to pass a freshman
level programming course can code up DES (hence 3DES) in a day.
Other algorithms will take even less. (RC4, for example, takes only
minutes.)
What you get with off the shelf crypto apps is a user interface,
better key management, etc. But if all you want to do is to protect
your files from snoops, an afternoon in a quiet corner suffices.
The terrorist argument is absolutely 100% a red herring. When you
see Freeh making it, he's lying, no question about it.
paul
------------------------------
From: jay <[EMAIL PROTECTED]>
Subject: Re: What the hell good is a session key!
Date: Tue, 24 Aug 1999 17:57:08 GMT
Anton Stiglic wrote:
>
> > [...] used to transfer session keys for a
> > symmetric
> > algorithm, symetric encryption being much harder to crack and
> > mathematically more secure than asymetric algorithm for any given key
> > length, meaning shorter keys (more performance) can be used for the
> > actual grunt work of the session, and meaning less ciphertext exposed
> > for analysis for any given key.
>
> symetric schemes much harder to crack? I might mention that alot of cryptologues
>
> beleive strongly that asymmetric encryption is much harder to break. Most
> asymmetric encryption base their security in some sort of strongly structured
> mathematical problem. For example, in ElGamal, it is know that the security of
> ElGamal encryption performed in certain classes of groups is equivalent to
> the Discret Log Problem, a highly structured mathematical problem, you won't
> find a symetric key encryption scheme that has that kind of "mathematical
> security" (as you say). It is true that symmetric key algorithms, most
> generaly,
> use shorter keys, but that is _NOT A VALID ARGUMENT_ to say that it
> is more secure. Even when comparing symmetric schemes between themselves,
> key lenght difference is not a mesure of security.
> The only valid point you mentioned is that symmetric schemes are generaly
> faster then asymmetric shemes, this is why, for large sizes of data, symetric
> schemes might be preferable.
Nope.
"Math" by itself doesn't mean squat to security.
Making symmetric algorithms with huge keys that mindlessly
but thoroughly scramble bits is trivial (and then
there are onetime pads). The
key is secret and must be reconstructed through looking
at tons of cyphertext. Symmetric algorithms
are based on math problems, like here's a big N and
N = p * q, p,q prime, "I dare you to find p and q."
The private key can be directly generated from
the public key, its just hard. An Uber-intellegent
Space Alien with incomprehensible math theories at his
disposal could maybe calculate them in his head.
We don't know, we only conjecture that its a
hard to practically impossible problem to solve
because we don't know a solution. But there
are no mathematical proofs that these problems
cannot be solved. If you read, "Applied Cryptography",
there is a place where the author says the
mathematical base problems for the current asymmetric
schemes are very few and its scary because
advances in math could topple many of the
current schemes in one blow.
Jay
don't know how
------------------------------
From: jay <[EMAIL PROTECTED]>
Subject: Re: What the hell good is a session key!
Date: Tue, 24 Aug 1999 18:00:34 GMT
jay wrote:
>
> Anton Stiglic wrote:
> >
> > > [...] used to transfer session keys for a
> > > symmetric
> > > algorithm, symetric encryption being much harder to crack and
> > > mathematically more secure than asymetric algorithm for any given key
> > > length, meaning shorter keys (more performance) can be used for the
> > > actual grunt work of the session, and meaning less ciphertext exposed
> > > for analysis for any given key.
> >
> > symetric schemes much harder to crack? I might mention that alot of cryptologues
> >
> > beleive strongly that asymmetric encryption is much harder to break. Most
> > asymmetric encryption base their security in some sort of strongly structured
> > mathematical problem. For example, in ElGamal, it is know that the security of
> > ElGamal encryption performed in certain classes of groups is equivalent to
> > the Discret Log Problem, a highly structured mathematical problem, you won't
> > find a symetric key encryption scheme that has that kind of "mathematical
> > security" (as you say). It is true that symmetric key algorithms, most
> > generaly,
> > use shorter keys, but that is _NOT A VALID ARGUMENT_ to say that it
> > is more secure. Even when comparing symmetric schemes between themselves,
> > key lenght difference is not a mesure of security.
> > The only valid point you mentioned is that symmetric schemes are generaly
> > faster then asymmetric shemes, this is why, for large sizes of data, symetric
> > schemes might be preferable.
>
> Nope.
> "Math" by itself doesn't mean squat to security.
> Making symmetric algorithms with huge keys that mindlessly
> but thoroughly scramble bits is trivial (and then
> there are onetime pads). The
> key is secret and must be reconstructed through looking
> at tons of cyphertext. Symmetric algorithms
Oops, that's "Asymmetric".
> are based on math problems, like here's a big N and
> N = p * q, p,q prime, "I dare you to find p and q."
> The private key can be directly generated from
> the public key, its just hard. An Uber-intellegent
> Space Alien with incomprehensible math theories at his
> disposal could maybe calculate them in his head.
> We don't know, we only conjecture that its a
> hard to practically impossible problem to solve
> because we don't know a solution. But there
> are no mathematical proofs that these problems
> cannot be solved. If you read, "Applied Cryptography",
> there is a place where the author says the
> mathematical base problems for the current asymmetric
> schemes are very few and its scary because
> advances in math could topple many of the
> current schemes in one blow.
>
> Jay
>
> don't know how
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: One-time pad encryption.
Date: Tue, 24 Aug 1999 13:32:28 -0400
"Tony L. Svanstrom" wrote:
>
> Please explain the weakness of this senario (besides the fact that the
> "key" has to be within reach and that finding "random" characters
> usefull to be used might in field be quite hard):
> ...
> Added to the above is then the next OTP to be used (not for the reply,
> but for the next encrypted message from that agent):
>
> xxxxx
> 12345
> xxxxx
> xxxxx
> 67890
> 12345
> 09876
> 54321
> 09876
> 54321
> 09876
> 54321
>
> That "packet" is then being "encrypted" using the OTP from the last
> message, the OTP is used twice to cover the 2([length of the OTP]) long
> message.
>
> My reasoning is that using the OTP twice shouldn't weaken this based on
> the fact that the second time it's being used it's used on a "text" that
> has been randomly picked and that contains no words or any other
> information that could be compared to the known to be a text part of the
> message (where the known to be text-part has been located by knowing the
> basic structure of this method).
What you describe sounds like what the Russians did around WW2; it
was broken in a project called Venona. See "Spycatcher" by Peter
Wright for some modest amount of detail.
paul
------------------------------
From: [EMAIL PROTECTED]
Subject: Help: DES Encryption -> ASCII
Date: Tue, 24 Aug 1999 18:37:20 GMT
Hi,
Can I use the DES encryption to generate an ASCII encrypted string so
that I can save it in a text file?.
Or do I have store the most significat bits of all bytes and append
some more ASCII bytes containing these bits to the encrypted buffer so
as to make the whole string ASCII?.
I would appreciate if someone can point me to some links.
Thanks in advance,
Mohan.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: One-time pad encryption.
Date: Tue, 24 Aug 1999 21:20:46 +0200
"Tony L. Svanstrom" wrote:
>
> Is this the best possible way to implement OTP in a everyday situation
> where you want to send secure messages?
>
No. This system is severely broken.
a) A single known-plaintext will reveal the contents of many other
messages.
b) If you XOR the first half of a message with the second half of
the previous message you can get two messages encrypted with the
same pad, like this:
Message 1:
AAAAA (Where A is plaintext 1 XORed with pad P)
AAAAA
AAAAA
AAAAA
BBBBB (Where B is the next pad, Q, XORed with pad P)
BBBBB
BBBBB
BBBBB
Message 2:
CCCCC (Where C is plaintext 2 XORed with pad Q)
CCCCC
CCCCC
CCCCC
If I XOR block B with Block C then I get plaintext 2 XORed with
pad P - ie. I now have message 1 and message 2 encrypted with the
same pad, P.
I can keep on chaining blocks together like this to reveal as many
messages as I want to, all of them XORed with the initial pad P.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: DES key parity!
Date: Tue, 24 Aug 1999 12:34:48 -0400
John Halliwell wrote:
>
> I know DES uses only 56 bits out of a 64 bit key and that the parity of
> the key should be odd, but is the parity check mandatory or just
> optional?
>
> What should happen if the key parity isn't odd?
>
> The standard seems to specify that the eigth (LSB) bit of each byte
> "may" be used for error checking, can a key expressed as 64 bits be
> valid if it contains even parity?
The fact it says "may" means parity checking is optional.
It's pretty much useless. If you do manual keying, I suppose an
argument could be made for it. Then again, I've never seen an
implementation of DES that implemented parity checking; they all
just ignore the parity bits.
If you do automatic keying, for example with IKE if you use
IPSEC, then clearly the parity bits MUST be ignored because
the D-H key agreement process won't generate keys with valid
parity...
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Xedia Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over
! any member of a civilized community, against his will, is to prevent
! harm to others. His own good, either physical or moral, is not
! a sufficient warrant." -- John Stuart Mill, "On Liberty" 1859
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Updated paper on ECDSA
Date: 24 Aug 1999 19:11:42 GMT
The correct URL is
http://cacr.math.uwaterloo.ca/~ajmeneze/publications/ecdsa.ps.
Don Johnson
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: What the hell good is a session key!
Date: Tue, 24 Aug 1999 13:10:52 -0400
Eric Lee Green wrote:
> Anton Stiglic wrote:
> > In the project I'm working at, master key is RSA-2048 bit, session
> > keys (that last about a month), is 1024 bit. We also have different levels
> > of master keys,
>
> Hmm. I thought the whole point of master keys was that they were for an
> asymetric algorithm used to transfer session keys for a symmetric
> algorithm, symetric encryption being much harder to crack and
> mathematically more secure than asymetric algorithm for any given key
> length, meaning shorter keys (more performance) can be used for the
> actual grunt work of the session, and meaning less ciphertext exposed
> for analysis for any given key.
>
Yes, master keys are used for that. But they are also used for PKI.
Whereas you want to validate a signature, you verify it with a master
key, or build up a hierarchy. One simple hierarchy, mixing stuff together,
is this:
Alice generates a symetric key, signs it with a montly public key and
encrypts with a public key , then sends it to Bob. Bob decrypts it and
verifies the signature with the montly key, but then, also verifies the
montly key using the master key.
anton
------------------------------
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: simple message encryptor for ICQ like programs
Date: 24 Aug 1999 18:01:39 GMT
In <7pl0lc$p43$[EMAIL PROTECTED]> Tom St Denis <[EMAIL PROTECTED]> writes:
>In article <7pkbuv$pb0$[EMAIL PROTECTED]>,
> Michael J. Fromberger <[EMAIL PROTECTED]> wrote:
>> Why don't you have a look at Arnold Reinhold's "CipherSaber" page, at:
>>
>> http://ciphersaber.gurus.com/
>>
>> CipherSaber-1 is similar in design to yours, and if you converted
>> your program to use it, you'd be interoperable with anyone else who
>> already has a CS-1 implementation (such as myself, for example! :)
>Good point... well my program was intended to be compact and just for
>online chat.. I dunno about cybersaber but mine is not for files or
>anything like that.
>
>If demand is high enough I will change the format, but I rather keep
>to my simple format unless I need to change.
For what it's worth, CipherSaber is about the simplest format there
is. It's a 10-byte IV, plus the ciphertext. That's all -- it doesn't
get much simpler than that! Why invent a new "simple" format, when
you can use one that's already well-publicized?
Cheers,
-M
--
Michael J. Fromberger Software Engineer, Thayer School of Engineering
sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
Z0UjAe/Nq4mYuohlNyZuNaPu/CPbUNFUTsRiBAEAtdpCnvGR+DzTVcB2akadeFSkLNJ1UeQj
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: What the hell good is a session key!
Date: Tue, 24 Aug 1999 13:21:02 -0400
> [...] used to transfer session keys for a
> symmetric
> algorithm, symetric encryption being much harder to crack and
> mathematically more secure than asymetric algorithm for any given key
> length, meaning shorter keys (more performance) can be used for the
> actual grunt work of the session, and meaning less ciphertext exposed
> for analysis for any given key.
symetric schemes much harder to crack? I might mention that alot of cryptologues
beleive strongly that asymmetric encryption is much harder to break. Most
asymmetric encryption base their security in some sort of strongly structured
mathematical problem. For example, in ElGamal, it is know that the security of
ElGamal encryption performed in certain classes of groups is equivalent to
the Discret Log Problem, a highly structured mathematical problem, you won't
find a symetric key encryption scheme that has that kind of "mathematical
security" (as you say). It is true that symmetric key algorithms, most
generaly,
use shorter keys, but that is _NOT A VALID ARGUMENT_ to say that it
is more secure. Even when comparing symmetric schemes between themselves,
key lenght difference is not a mesure of security.
The only valid point you mentioned is that symmetric schemes are generaly
faster then asymmetric shemes, this is why, for large sizes of data, symetric
schemes might be preferable.
Anton
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: What the hell good is a session key!
Date: Tue, 24 Aug 1999 12:28:05 -0700
Anton Stiglic wrote:
>
> > [...] used to transfer session keys for a
> > symmetric
> > algorithm, symetric encryption being much harder to crack and
> > mathematically more secure than asymetric algorithm for any given key
> > length, meaning shorter keys (more performance) can be used for the
> > actual grunt work of the session, and meaning less ciphertext exposed
> > for analysis for any given key.
>
> symetric schemes much harder to crack? I might mention that alot of cryptologues
> beleive strongly that asymmetric encryption is much harder to break.
Note that I said *FOR A GIVEN KEY LENGTH*.
The deal is that not all combinations of 2048 bits are a valid RSA key,
while all combinations of 128 bits are a valid TwoFish key (well,
theoretically speaking anyhow... I haven't cryptoanalyzed TwoFish to
know whether it has any weak keys, but you get the point). In addition,
the public key and private key in assymetric algorithms are
mathematically related, so it is hypothetically possible that some
advance in mathematics could produce a solution to the "hard problem"
that underlies a particular form of public key encryption.
> security" (as you say). It is true that symmetric key algorithms, most
> generaly,
> use shorter keys, but that is _NOT A VALID ARGUMENT_ to say that it
> is more secure. Even when comparing symmetric schemes between themselves,
> key lenght difference is not a mesure of security.
If you are measuring resistance to brute-force attacks, the number of
possible keys is the measure you're interested in. And you are correct
that number of bits is not the ultimate measure of security, since many
algorithms either cannot use all possible combinations of bits as valid
keys (all asymmetrical algorithms), or else there are keys that produce
the same cyphertext from the same plaintext, or which are succeptible to
known-plaintext attacks, or etc. All I noted was that FOR A GIVEN KEY
LENGTH, a good symmetrical algorithm is going to have more possible keys
and thus be harder to break via brute force methods. Thus I would highly
recommend against using 1024-bit RSA for session keys if you're using
2048-bit RSA for master keys -- even today, 1024-bit RSA is only
marginally secure, while 2048-bit RSA will probably remain secure for
quite some time (assuming no major advancements in the factoring "hard
problem" that underlies RSA).
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: What the hell good is a session key!
Date: Tue, 24 Aug 1999 15:07:44 -0400
>
> cannot be solved. If you read, "Applied Cryptography",
> there is a place where the author says the
> mathematical base problems for the current asymmetric
> schemes are very few and its scary because
> advances in math could topple many of the
> current schemes in one blow.
Of cours, Bruce Schneier, author of Blowfish and great cryptanalyst
of symmetric cipher, is going to have a point of view that gives
positive arguments to symmetric encryption compared to asymmetric.
(no disrespect to Mr. Schneier, I repsect him alot).
Go read a cryptographic book written by a cryptologue with more of
a 'information complexity/mathematical" background, and you'll get
a totaly different point of view. Read something from Luby, Yao, Brassard
(I can name dozens more). Nobody, in the present moment, can say
whether asym. or sym. schemes are more secure. Yes, the mathematical
basis for asymmetric schemes are few, but solidely based. The person who
gets an algorithm to solve FACTORING, or DLP or DHP is gonna be rich,
and beleive me, there has been thousands that have tried, and have tried
longer then cryptanalyst have tried to break symmetric schemes.
Using your scenario, there is no reasons to suspect that an alian might not
be able to brute force attach BLOWFISH, or found some short cut to
cracking it.
I can't tell you asymmetric schemes are more secure than symmetric,
I can't tell you the opposite either, I will not beleive anybody posing
statements on that subject either unless he gives me concrete proof (such as
an algo to factor, or a proof that factor is realy in fact hard).
I beleive each person can take an educated guess (my guess is that I'd vote
for RSA as opposed to BLOWFISH if my life would depend on it), but I don't
beleive anybody can just boldly state that symmetric encryption is better than
asymmetric (or vis versa), and I don't respect the cryptographic judgment of
someone who would.
Anton
------------------------------
** 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
******************************
