Cryptography-Digest Digest #106, Volume #10 Tue, 24 Aug 99 19:13:02 EDT
Contents:
Re: cryptographic DLL (JPeschel)
Re: Attacks on RC4 ? (David Wagner)
Re: CRYPTO DESIGN MY VIEW (Mok-Kong Shen)
Re: cryptographic DLL (David A Molnar)
Re: What the hell good is a session key! (Eric Lee Green)
Re: cryptographic DLL (Tom St Denis)
Re: simple message encryptor for ICQ like programs (Tom St Denis)
Re: Multiple Hash Algorithms and Birthday Attacks (Tom St Denis)
Re: Help: DES Encryption -> ASCII (Doug Stell)
Re: Help: DES Encryption -> ASCII
Re: Multiple Hash Algorithms and Birthday Attacks
credits in PeekBoo and CDLL (Tom St Denis)
Re: cryptographic DLL (Greg)
Re: The Reversal of NetNanny ([EMAIL PROTECTED])
export legislation (Kurt Wismer)
Re: CRYPTO DESIGN MY VIEW (Mok-Kong Shen)
Re: cryptographic DLL (Tom St Denis)
Re: export legislation (Eric Lee Green)
Re: What the hell good is a session key!
Re: What the hell good is a session key!
Re: cryptographic DLL (Greg)
Re: cryptographic DLL (Greg)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: cryptographic DLL
Date: 24 Aug 1999 21:01:08 GMT
Tom St Denis <[EMAIL PROTECTED]> writes:
>For the inquiring minds I am now a 'clueless-hacker' interested in
>breaking the law or messing things up. I am quite lawful, xcept when
>it comes to 'silly' laws made by crypto-clueless people. EAR is like
>saying 'no car for you, you might hit someone' or 'no gun for you, you
>might shoot someone' etc...
>
>Basically EAR rules are the wierdest most abstract useless laws I have
>heard of. Make 'strong-crypto' illegal and we will all just become
>criminals...
Tom, you may be putting yourself in a difficult position, as the crypto
export laws in Canada are quite similar to those in the US.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Attacks on RC4 ?
Date: 24 Aug 1999 13:01:30 -0700
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/
Yes. Paul's result is a very interesting one.
Andrew Roos' post can be found by doing a websearch for "weak keys in RC4".
Mine is at <http://www.cs.berkeley.edu/~daw/my-posts/my-rc4-weak-keys>.
Also, you may want to read Jovan Golic's paper on RC4. It's in one of the
recent EUROCRYPT proceedings.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Tue, 24 Aug 1999 23:11:23 +0200
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
><[EMAIL PROTECTED]> wrote:
> >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.
>
> I took the liberty of showing what was above since you don't seem to read
> what I wrote
> >> xxxxxxxx xxxxxxx_ is a valid bit stream that can lead to
> >> xxxxxxxx xxxxxxx0 for most cases this is finally compress file
>
> if you look carefully your code kind of matches the case above
> so it would most likely match ...abc
I like to have a more definite answer, not a probabilistic kind
of answer. Since you are the author of your program, could you
kindly say whether the answer is surely (1) or (2), i.e. without or
with error message? This has namely fairly important bearing on what
we have been discussiog up till now. Thanks.
M. K. Shen
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: cryptographic DLL
Date: 24 Aug 1999 20:10:54 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> Well it has Twofish and Blowfish with no restrictions on the keysize.
> The thing is I don't care about EAR. They will not send a 17 year
> old 'kid' to jail, and even if they did, I could protest how stupid
> those rules are and why they are unconstitutional.
Also, you're Canadian, aren't you ?
-David
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: What the hell good is a session key!
Date: Tue, 24 Aug 1999 20:52:25 GMT
Greg wrote:
> If this is what you were saying- in effect- then I think speed (session
> key) and convenience (public key) combined is the answer to your
> question. However, I feel that speed is not as important for things
> like e-mail where a public key cryptosystem can be used exclusively and
> make for only one point of potential weakness. See www.ciphermax.com
> for more details on my view point.
I think part of his argument was to reduce the amount of ciphertext that could
be used to attack the public key. In addition, a larger number of bits/more
computationally intensive algorithm could be used for the public key portion of
the system. Thus the usual method of using a compute-heavy asymmetric scheme to
authenticate and encrypt the session keys, and a (less computationally
intensive) symmetric scheme with session keys to do actual data transfer.
If you are only transferring small EMAIL messages using a public key
cryptosystem, I agree that a session key setup is going to be unnecessary
overhead. But not all EMAIL messages are small.
-E
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: cryptographic DLL
Date: Tue, 24 Aug 1999 21:37:37 GMT
In article <7pv1n6$h5j$[EMAIL PROTECTED]>,
Greg <[EMAIL PROTECTED]> wrote:
> Well, thanks for clearing that up for me.
>
> I would advise you, but I am not a lawyer. The most I can do is tell
> you to get one. Hick, if you want to be my evening news, forget it.
I
> don't watch those liars anymore.
Thanks for the concern, however I am trying to make a statement. I am
trying to release a cryptographic DLL. It's still missing a RNG (which
I will be adding tonight).
I want to make a website for it too.
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: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: simple message encryptor for ICQ like programs
Date: Tue, 24 Aug 1999 20:57:20 GMT
In article <7pumm3$175$[EMAIL PROTECTED]>,
Michael J. Fromberger <[EMAIL PROTECTED]> wrote:
> 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?
Well maybe so. But again CipherSaber is for files and pipes, my
program is for online messages. It has a 64-bit salt with a 32-bit
size field. It prevents corrupted packets from killing the computer.
Plus my program has a few more features (auto-decrypt, more ciphers,
auto-binhex, hexbin ..)....
Check it out at: http://people.goplay.com/tomstdenis/pb.html
btw, I am not saying CS bad, I am just saying my program serves a
slightly different purpose.
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: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Multiple Hash Algorithms and Birthday Attacks
Date: Tue, 24 Aug 1999 21:02:12 GMT
In article <7putpg$e0h$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I know that a birthday attack is used to find two files, for example,
> that hash to the same value. My question is, if you find a pair of
> files, a & b, that hash to the same value using a specific hash
> function, would those two files have identicle hashes using a
different
> hash function? If no, would it be a good idea to send two hashes
with a
> file, say one hashed with SHA and another hashed with MD5. I know
there
> are hash functions that produce large hashes, such as HAVAL. I'm just
> thinking that it would be harder to find a pair of files, a & b, that
> would produce identicle hashes for two algorithms than just one
> algorithm.
Well it's true that collisions of n-bit inputs will be different for
two different algorithms, genreally that's not required. The most
usefull attack on a hash, is to forge a pre-image. For example I send
a message, with a hash I would have to find another document that says
what I want to say, looks like it is from the other person and hashes
to the same value. This constitutes a brute-force style attack of the
hash function.
The birthday-attack works when you are trying to find colisions with
two random files (or sources). But does not constitute real messages.
Generally against SHA-1 finding a collision that resembles english
text, says the same idea but changed actions (i.e give me 1000 dollars,
instead of 100 dollars ...) is really really really hard todo.
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] (Doug Stell)
Subject: Re: Help: DES Encryption -> ASCII
Date: Tue, 24 Aug 1999 21:24:49 GMT
On Tue, 24 Aug 1999 19:53:36 GMT, Tom St Denis
<[EMAIL PROTECTED]> wrote:
>In article <7puoov$a5s$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> Hi,
>>
>> Can I use the DES encryption to generate an ASCII encrypted string so
>> that I can save it in a text file?.
>Well you could simply uuencode the binary data to the text file. But
>as you might have already noted DON'T USE DES. If this is a new
>application seek out another algorithm. If it's an older/compliant
>application use uuencode (on the DES output).
Most modern systems use radix-64 or IA5 encoding, rather than
UUENCODE, for binary<->text conversion. UUENCODE is efficient, but is
closely tied to ASCII. IA5 is not tied to the encoding of the
characters.
The 3 byte to 4 character chinking is the same. IA5 has a termination
character (=) for incomplete 3 byte blocks at the end. Unlike
UUENCODE, IA5 does not have a space in its encoding and is, therefore,
immune to trailing space deletion and does not need the line-length
prefix (M) on each line.
6-bit partitions encode as follows:
0 - 25 decimal encode to A - Z
26 - 51 decimal encode to a - z
52 - 61 decimal encode to 0 - 9
62 decimal encodes to +
63 decimal encodes to /
= is the pad character
The question applies to any block cipher that outputs in binary and
not just to DES.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Help: DES Encryption -> ASCII
Date: 24 Aug 99 21:46:42 GMT
[EMAIL PROTECTED] wrote:
: 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?.
If you mean, is there a way to encrypt something with DES, and guarantee
that the eight bytes produced will all be ASCII printable characters, no
there is not: unless you start with the eight printable characters, and
decrypt them first.
The ususal technique is to take six bits at a time, and represent
each group of six bits by one character from a restricted set consisting
of all the uppercase letters, all the lowercase letters, all the digits,
and two additional special characters. A third special character, =, is
used to fill up any unused part of a block of four characters (which
exactly represent three bytes).
This is called Base-64 encoding.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Multiple Hash Algorithms and Birthday Attacks
Date: 24 Aug 99 21:42:51 GMT
[EMAIL PROTECTED] wrote:
: I'm just
: thinking that it would be harder to find a pair of files, a & b, that
: would produce identicle hashes for two algorithms than just one
: algorithm.
Oh, yes, it certainly would be harder. And the more the two hash
algorithms are different in design from one another, the better.
John Savard
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: credits in PeekBoo and CDLL
Date: Tue, 24 Aug 1999 21:08:42 GMT
I am making a public apology to Ruud de Rooij for omitting him in the
credits for his Twofish code. The new binaries/source for PeekBoo and
CDLL (the cryptographic DLL) are now updated and online.
If I omitted anyone else I apologize in advance and will make the
required changes promptly.
PeekBoo
http://people.goplay.com/tomstdenis/pb.html
CDLL
http://people.goplay.com/tomstdenis/cdll.zip
--
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: Greg <[EMAIL PROTECTED]>
Subject: Re: cryptographic DLL
Date: Tue, 24 Aug 1999 21:10:10 GMT
> > Well it has Twofish and Blowfish with no restrictions on the
keysize.
> > The thing is I don't care about EAR. They will not send a 17 year
> > old 'kid' to jail, and even if they did, I could protest how stupid
> > those rules are and why they are unconstitutional.
> >
> > Basically I don't care about EAR. The source is there you can check
> it
> > out if you want.
>
> For the inquiring minds I am now a 'clueless-hacker' interested in
> breaking the law or messing things up. I am quite lawful, xcept when
> it comes to 'silly' laws made by crypto-clueless people. EAR is like
> saying 'no car for you, you might hit someone' or 'no gun for you, you
> might shoot someone' etc...
>
> Basically EAR rules are the wierdest most abstract useless laws I have
> heard of. Make 'strong-crypto' illegal and we will all just become
> criminals...
Well, thanks for clearing that up for me.
I would advise you, but I am not a lawyer. The most I can do is tell
you to get one. Hick, if you want to be my evening news, forget it. I
don't watch those liars anymore.
--
The US is not a democracy - US Constitution Article IV Section 4.
Democracy is the male majority legalizing rape.
UN Security Council is a Democracy. NO APPEALS! Welcome to the NWO.
Criminals=Crime. Armies=Tyranny. The 2nd amendment is about tyranny.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: The Reversal of NetNanny
Date: Tue, 24 Aug 1999 21:56:12 GMT
> Very interesting article. I enjoyed reading it -- this definitely is
> a sci.crypt type of article, IMHO. Good semi-formal write up that was
> accurate but keeps your interest, without adding unnecessary technical
> detail.
Thanks, it's always nice with some feedback.
> Keep us posted on future achievements.
Sure. There's lot's of "snake oil" out there. I thought I'd take a look at
that "Ciphile OAP-L3" software, if only I could download it. If "Ciphile" is
reading this, please send the package over. I've asked for it before in email
but nothing came out of it. You said you couldn't export it, but that you'd
let me take a look at the PRNG.
--
Saruman ([EMAIL PROTECTED]) - http://hem2.passagen.se/eddy1/reveng/
"Copy-protected disk: an elegant device for training
the next generation of assembly language programmers."
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Kurt Wismer)
Subject: export legislation
Date: Tue, 24 Aug 1999 20:43:14 GMT
could i inquire about the current state of affairs with regards to u.s.
export restrictions on cryptographic software? (ie. is itar more or less
still intact?)
--
Making sure everyone gets Internet access whether they can afford it or not.
Also good as a backup to a commercial ISP account, or a stepping stone to one.
See http://www.torfree.net for info on membership, charitable donations,
advertising, or all kinds of info about Toronto. * The Toronto Free-Net *
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Tue, 24 Aug 1999 00:08:13 +0200
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
><[EMAIL PROTECTED]> wrote:
> >SCOTT19U.ZIP_GUY wrote:
> >>
> >> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> > <[EMAIL PROTECTED]> wrote:
> >>
> >> >
> >> >To be exact, you can't say how many input symbols are obtained from
> >> >the x's. For instance, it could be that there are Huffman codes
> >> >that occupies only 3 x positions. All one knows (by our assumption)
> >> >is that the last 9 bits of the original output file constitute one
> >> >single Huffman code and therefore these 9 bits will be decompressed
> >> >to one input character (which, if it is 8 bit ASCII, occupies a byte).
> >> >But this fact is unimportant for the present discussion.
> >> What are you thinking I thought the x's where a single token.
> >> Look it is obvious you are lost and don't know what I mean. PLEASE
> >> ASK SOMEONE ELSE FOR HELP.
> >
> >Eh?? What was wrong?? There were 7 x's, each being a bit position,
> >so it could well be that 3 of the bits consitute one Huffman code.
> >That each x represent a bit in the output file (compressed file)
> >should have been entirely clear to you in all the discussions up
> >till now!!!!!
> Get real the 7 x's where only one token. Your are the one who just
> said maybe 3 of the x's are part of a token and the 7'x could be more than
> one token. You don't have a clue.
What are your understanding of a binary file????? I listed only the
last 2 bytes without specifying whether these are 0 or 1. The last
Huffman code had, by assumption, 9 bits and hence was represented
by 9 y's. The x's represent bits from any (unspecified) number of
Huffman codes. If I were to describe the last 5 bytes, I would
have written as follows:
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxy yyyyyyyy
I use all x's to represent the bits preceeding the last Huffman code,
because it doesn't matter how the different Huffman codes preceeding
the last one look like. Do you understand now that the last 7 x's
(in the preultimate byte) need not (may, but not necessarily) be
one single Huffman code?????
> >
> >> My method takes "ANY BINARY FILE" call that file "A" and decompresses to a
> >> file call that FILE "B". If you compress file "B" you get exactly "A" back
> >> PERIOD.
> >> Also you can take FILE "A" compress it to a FILE "C" take FILE "C" when
> >> you decompress it you get FILE "A" back exactly.
> >> This is "one to one" compression decompression. There is no wrong
> >> file except in your mind. The method used is "adaptive huffman compression"
> >> it is exactly like the huffman bit stream except that sometimes it is left
> >> alone. Sometimes it is zero filled and sometimes the last partial byte is
> >> chopped off altogether. I am done talking to you.
> >
> >This is COWARD in scientific discussions!!! When shown by others that
> >you are wrong, you simply discontinue the argumentation. You snipped
> >and did not refer at all to the ESSENTIAL paragraph of mine in the
> >previous post which explained in detail (based on assertions of your
> >own) that your program, when encountering the 0 bit of my example
> >which it can't deal with, simply ignores the error (abnormal)
> Your a fucking idot the encountering of the last 0 in the case we
> where talking about is not an ERROR. IF you don't have the mental
> abiltity to get beyond this point. What is there left to discuss. You
> can rant and rave and call it an error just because you have a closed
> mind. But if it is an error construct a file to show this. You can't because
> you are are messed up.
> >condition. This shows that your program violates the very elementary
> >requirements of program correctness and consequently all you
> >hard-necked claims (without proof) of the 'one to one' property are
> >only an illusion, if not downright cheating!!!
> I'm sorry but I think your FULL of SHIT. OR suffering from a brain
> piron infection. If you think there is an error find one example of a finite
> (not over several megabtyes that does not compress and recover after
> decompression. Or the opposite decompress the file and than compress it. If it
> does not do this then my code has an error. But your insane ramblings do not
> show an error. Like I said you have the code but unfortunately even after
> I have tried many times to help you understand for some reason you seem
> incabable of following a simple thought. Nothing personnel but you may need
> imediate medical attension.
> >
> >I want to explicitly call the attention of all participants of this
> >group to your present behaviour in this discussion thread so that
> >they will well use it as a hint to help them judging the quality of
> >your programs and the scientific trustworthiness of your often
> >made claims (without accompanying proofs) in the field of cryptology.
> >
> And I would like someone to follow this thread and see who is lost.
> This is impossible to get anything through his head. Have any others
> been successful discussing anything basic with this individual. IF you have
> please try to explain what is going on in my dynamic huffman compression
> program becasue he is clueless.
The very dirty words you employed above and also in your last
follow-up don't belong to the vocabulary of ANY educated person!!!
It's extremely deplorable that such stuffs ever come into scientific
discussions that are, in particular, in written form and further get
archived for future reference (by both members of this group and
outsiders). It is a shame that discussion in this group ever came
down to such a low level. It is really time to stress that we are
in a sci-group not in a chat room!!!
M. K. Shen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: cryptographic DLL
Date: Tue, 24 Aug 1999 22:01:02 GMT
In article <7puu8e$jlj$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > Well it has Twofish and Blowfish with no restrictions on the
keysize.
> > The thing is I don't care about EAR. They will not send a 17 year
> > old 'kid' to jail, and even if they did, I could protest how stupid
> > those rules are and why they are unconstitutional.
>
> Also, you're Canadian, aren't you ?
Pardon my ignorance of EAR and crypto-law but what does being Canadian
have anything todo with this? I though the US (i.e Bush) made sure
that the reach of 'crypto-laws' extended well to Canada....????
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: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: export legislation
Date: Tue, 24 Aug 1999 22:09:00 GMT
Kurt Wismer wrote:
> could i inquire about the current state of affairs with regards to u.s.
> export restrictions on cryptographic software? (ie. is itar more or less
> still intact?)
You could, but it'd be best to take it to talk.politics.crypto, since that's
what it all boils down to.
-E
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: What the hell good is a session key!
Date: 24 Aug 99 22:12:46 GMT
Anton Stiglic ([EMAIL PROTECTED]) wrote:
: 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).
Well, _for a given key length_, there is hard evidence that algorithms
like RSA are at a disadvantage, since numbers 128 bits long, and longer,
of no special form, have been factored.
And a brute-force attack, at least, against a cipher with a 128-bit key is
quite impossible. Perhaps short-cut attacks against ciphers like Blowfish
of equal power as that of factoring will be possible someday, but there is
very little evidence to suggest that possibility.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: What the hell good is a session key!
Date: 24 Aug 99 21:57:29 GMT
Anonymous ([EMAIL PROTECTED]) wrote:
: Using only conventional encryption (like PGP if you check the conventional
: box) if an attacker can brute-force your session key in a month, then they
: can certainly subsequently brute-force your master key, if it is the same
: length.
Ah, this must be a new mode in recent versions of PGP.
The advantage of this kind of session key for security is: if they
_cannot_ quite brute-force the length of key used, _other_ techniques,
such as differential cryptanalysis, which requires a large amount of
plaintext, are hampered because each session key is used only for a short
message.
Until a session key is found, since the master key is directly used only
to encrypt session keys, which are random, a brute-force attack against
the master key cannot begin.
So your main point *is* correct: the use of a master key and session key
will not help you if the cipher you are using is so weak that a
brute-force attack against it is possible.
: As for public-key master
: keys, if an attacker can brute-force a 128+ bit session key in the first
: place, you better worry a bit about your public keys too.
Here, however, there is a reason for using a session key, and it has
nothing to do with more security. Enciphering the whole message with RSA -
and Diffie-Hellman can only be used to agree on a key for some other
system of encryption, not to encipher anything - is very slow.
And it is _not_ believed that we are facing attackers who can break
conventional encryption with a 128-bit key by brute force.
: In addition, someone might suggest using double encryption or multipass
: compression, or some other such thing. But consider the fact that those
: methods would not affect the number of possible keys, just the work factor
: of testing each one.
If one uses Triple-DES instead of DES, the number of possible keys _is_
changed, because one could try all 2^56 combinations for one of the layers
of DES, and in each case, the result would only be random-appearing
enciphered text. To solve by brute-force, all combinations in all the
stages must be tested at the same time.
John Savard
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: cryptographic DLL
Date: Tue, 24 Aug 1999 22:31:05 GMT
> Tom, you may be putting yourself in
> a difficult position, as the crypto
> export laws in Canada are quite similar
> to those in the US.
He wants to make a statement- he wants to go to jail.
And such a waste of a youthful life. So much tyranny to fight, so
little time.
--
The US is not a democracy - US Constitution Article IV Section 4.
Democracy is the male majority legalizing rape.
UN Security Council is a Democracy. NO APPEALS! Welcome to the NWO.
Criminals=Crime. Armies=Tyranny. The 2nd amendment is about tyranny.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: cryptographic DLL
Date: Tue, 24 Aug 1999 22:17:18 GMT
> Also, you're Canadian, aren't you ?
THAT'S IT! I can take my software to Canada, can't I? I can post it
there and flea back to the US, can't I? I will be wanted in Canada,
but not here!
Oh, well, may as well take a trip to Mexico...
--
The US is not a democracy - US Constitution Article IV Section 4.
Democracy is the male majority legalizing rape.
UN Security Council is a Democracy. NO APPEALS! Welcome to the NWO.
Criminals=Crime. Armies=Tyranny. The 2nd amendment is about tyranny.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
