Cryptography-Digest Digest #435, Volume #10 Thu, 21 Oct 99 15:13:04 EDT
Contents:
SSL description comments please... ("me")
Re: RSA Hardware ([EMAIL PROTECTED])
Re: RSA key size and encryption (Peter Gutmann)
Re: Another newbie question (Will Sloan)
is <your favorite algo here> a group? (Fiji)
Re: detecting backdoor in prime generator (Tom St Denis)
October 21st, 1999 is "Jam Echelon Day" (anonymous consumer)
NAI version of PGP 6.5.1 secure? (Erlenmyer RR. Flask)
Re: Math explaination of RSA public-key? (NFN NMI L.)
Re: is <your favorite algo here> a group? (Paul Koning)
Re: some information theory (very long plus 72K attchmt) ("Belldandy")
Re: some information theory (very long plus 72K attchmt) ("Belldandy")
Re: some information theory (very long plus 72K attchmt) (Tim Tyler)
Re: some information theory (very long plus 72K attchmt) (Anton Stiglic)
Re: some information theory (very long plus 72K attchmt) (Patrick Juola)
----------------------------------------------------------------------------
From: "me" <[EMAIL PROTECTED]>
Subject: SSL description comments please...
Date: Wed, 20 Oct 1999 16:45:46 -0500
To all,
First I'd like to thank everyone that participated in the previous threads.
I appreciated you're being patient, and explaining to me the err's (many,
many errors!) of my ways. I don't always get it right the first time, but I
don't give up till I get it right.
So here goes another (humbling again I'm sure) attempt to map out what
happens during a SSL session. Please feel free to read and comment on any
part(s) you wish. After everyone's done suggesting, I'll be re-doing this
and then using it as the foundation of fact for information that will
ultimately flow to our board members and members.
<clueless on>
Browser verifies the validity of the web servers' digital certificate with
Verisign or some other authenticating authority.
1. Browser asks the web server for two things:
A. Servers' public key
Server could be using 512-bit, most likely 1024-bit
B. What algorithm to use to generate the session key
DES, IDEA, RC4, RC5 etc.
Different browser and versions have different algorithms they use. Some are
strong, some not.
2. Web server then sends back to the browser it's public key and what
algorithms it supports.
3. Browser then generates a random session key using a algorithm that the
web server supports. (hopefully the highest?)
Browser type/version is crucial to key generation.
4. Browser then encrypts the random session key with the server's public key
and sends it to the web server.
5. Web server receives it and uses it's secret key to decrypt the
transmission and extracts the random session key that was generated by the
browser.
6. Web server then uses this random session key to encrypt the data it
sends to the browser.
7. The browser also uses this random session key to encrypt the data it
sends to the web server.
I heard rumor that step 6 & 7 use a separate key? True, False?
My interpretation of some other concerns:
1. Step 4 to me is security hole. If intercepted (see para 3 below), the
attacker must mimic the work that the research team used to break a 512-bit
RSA key. They would have to attack a specific web server's 512-bit RSA
secret key that was generated on that particular web server. Once broken,
the attacker would then be able to derive the random session key that was
generated by the browser. Once obtained, as long as the attacker continues
to intercept the transmission that encrypts the actual random session key,
they would have access to the data. This would continue until the web
server generated a new secret key. On most web servers, this is done
annually. Some re-generate it every time the server re-boots. Once
re-generated, the attacker would have to crack the new 512-bit key.
2. The random session key is going to be different each time the browser
starts a session with a web server. Some web servers will "expire" the
random session key in the middle of a session and force the browser to
re-generate another random session key.
3. To intercept the transmission, is itself a major undertaking. The
attacker would have to either directly connect some sort of recording device
to a line that all of the browser's data flows through, or make the browser
believe that a phony web server is the one it wants to talk to. Either way,
my understanding is that it's very difficult to intercept ALL data flowing
to or from a particular browser to derive the packets of data that contains
the random session key.
</clueless off>
Thanks for the help,
Michael Sorbera
Webmaster of a Federal Credit Union
"In the land of the clueless, he who has half a clue is King!"
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA Hardware
Date: Wed, 20 Oct 1999 21:45:58 GMT
In article <[EMAIL PROTECTED]>,
=?iso-8859-1?Q?Herv=E9=20Andr=E9?= <[EMAIL PROTECTED]> wrote:
> i work on implmentation of RSA in hardware
>
> [EMAIL PROTECTED] a écrit :
>
> > Could anyone please recomend any RSA Hardware related sites, or
offer
> > advice on implemtation of RSA in hardware.
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> Regarding the implementation in hardware, I am hoping to achieve this
using VHDL.
Any help with this would be greatly appreciated.
Rick
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: RSA key size and encryption
Date: 20 Oct 1999 22:15:43 GMT
Tom St Denis <[EMAIL PROTECTED]> writes:
>If your modulus is n bits, then you can generally encode anything upto
>n-1 bits in length. I would suggest having AT LEAST half of that as a
>random value. So if you had a 512 bit modulus you could encode 511
>bits, about 256 bits of which should be random junk. Obviously if you
>are sending [for example] 128 bit keys for a symmetric cipher you will
>have 511-128=383 random bits.
I just found out today that the German HBCI (Home Banking Computer Interface)
spec requires that encryption be performed on unpadded content-encryption keys,
and signatures on unpadded RIPEMD-160 hashes (that is, for the HBCI-standard
768-bit RSA key size you encrypt a value consisting of 640 zero bits and 128
key bits). This has no semantic security, but is there any real, exploitable
weakness in this? I know there are theoretical objections (P1363 covers this
pretty well) and I can't imagine why you'd risk using unpadded data when PKCS
#1 and OAEP are also available, but on the other hand I can't see any
showstopper attack on the HBCI format either.
Peter.
------------------------------
From: Will Sloan <[EMAIL PROTECTED]>
Subject: Re: Another newbie question
Date: Wed, 20 Oct 1999 17:04:08 -0700
Steve K wrote:
> On Wed, 20 Oct 1999 14:55:26 -0700, Will Sloan
> <[EMAIL PROTECTED]> wrote:
>
> >I have an assignment to decrypt some encrypted text. I have done a
> >frequency analysis of the letters and I believe it is english and has
> >just been encrypted by using a transposition cipher.
>
> Not much help here, but: I don't think it's a transposition cipher.
> If it is, it uses a *lot* of padding. Note the presence of many
> highly repetitive strings. It almost looks like an image file to
> me...
I should have said this eariler, but the attachment is not the cipher but
a gif of the frequency of letters plotted verus english. Sorry about
that.
------------------------------
From: Fiji <[EMAIL PROTECTED]>
Subject: is <your favorite algo here> a group?
Date: Wed, 20 Oct 1999 22:10:12 -0400
I have seen people discuss whether DES is a group. I believe I understnad
the issues if it were a group. The question is how come nobody seems to
worry about other algos? What about hashing algorithms? What about other
Feistel ciphers? Is it just because nobody has done this yet?
-Fiji
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: detecting backdoor in prime generator
Date: Thu, 21 Oct 1999 02:24:35 GMT
In article <7ukddd$nbk$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Patrick Juola) wrote:>
> Mr. Stiglic is suggesting a broken generator that doesn't select
> "random" primes.
>
> I could easily build one of these. Choose a set of 1000 primes
> and select p from one of them. Select q fairly and randomly.
> I could thus easily break any RSA key built by this set by
exhaustively
> searching my 1000 potential p's. On the other hand, you'd only have
> one chance in a million (-ish) of noticing the weakness by inspecting
> a pair of (generated) keys.
If I select a prime from a list of 1000, it is hardly random. I can't
see why he would ask this question though. It's pratically the same as
saying, I use a 64 bit key with 63 bits of zeros ...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: anonymous consumer <[EMAIL PROTECTED]>
Subject: October 21st, 1999 is "Jam Echelon Day"
Date: Thu, 21 Oct 1999 03:28:04 GMT
October 21st, 1999 is "Jam Echelon Day"
http://www.echelon.wiretapped.net/
http://www.wired.com/news/news/politics/story/22102.html
-only YOU can prevent BigBrother
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Erlenmyer RR. Flask)
Subject: NAI version of PGP 6.5.1 secure?
Date: Wed, 20 Oct 1999 22:30:27 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
I have had a version of PGP 6.51 from Network Asoc. Some1 from
IRC:efnet> #pgp floated a idea that they were installing some
backdoor. Or working with the gov't to make it EZ to get key or
decrypt emails.. etc. Your comments and such are appriated as I
wonder if my worries have warrant.
Thanks,
Erlenmyer RR. Flask
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.5.1
iQA/AwUBOA5CLbnk4cVxlWo3EQJekgCgjok+VRICPdXEs8WiCIN1yBGmNf8AoOXK
gHDeNa4O6mwOJwXI7M0rNHoR
=0ZIh
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (NFN NMI L.)
Subject: Re: Math explaination of RSA public-key?
Date: 21 Oct 1999 05:35:21 GMT
<<But it is usually chosen tomake calculating C easy.>>
Public exponent = 17? Weak! Try 65537.
S. "Too lazy to post anymore" L.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: is <your favorite algo here> a group?
Date: Thu, 21 Oct 1999 12:02:30 -0400
Fiji wrote:
>
> I have seen people discuss whether DES is a group. I believe I understnad
> the issues if it were a group. The question is how come nobody seems to
> worry about other algos? What about hashing algorithms? What about other
> Feistel ciphers? Is it just because nobody has done this yet?
I think the question is important if you do multiple
encryption -- which isn't normally done with anything
other than DES.
paul
------------------------------
From: "Belldandy" <[EMAIL PROTECTED]>
Subject: Re: some information theory (very long plus 72K attchmt)
Date: Thu, 21 Oct 1999 11:50:31 -0500
Anton Stiglic <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> The statistical characteristics are not hidden when you compress.
> If I'm looking for 'e' for example, I just look for Comp('e') instread,
> if I'm looking for 'e' followed by 'd' s, I look for Comp('ed').
huh?
1. Remember that you're working from a cypher text.
2. Remember that the function of Comp is often no per-block. If you're
looking for e (because e is the most frequent), the e won't be simply
replaced by another symbol (for instance x). COmpression most likely in the
form of symbol + frequency + whatever.
3. By the assumption that the compression is... unstructured(?), the job
from uncompressed cypher text is more difficult than compressed form since
you have to make sure the correct association between frequency and symbol..
4. well, of course there can always be compression type where it makes the
attack easier. For example: for 64 bit block compression, i dedicate the
first 64 bit for the truth value of letter A existence in the first byte,
2nd 64 bit for truth value of B in the 1st byte, ...., 26th 64 bit for truth
value of Z in the 1st byte, 27th 64 bit for truth value of A on the 2nd
byte................. And then make everything that is not 00F0000000000000
as True.
by the theorm which say that there is no compression algo that can always
compress data of N byte into less than N byte, I think I'm .....kind of
justified in using that kind of compression. :-) :-)
------------------------------
From: "Belldandy" <[EMAIL PROTECTED]>
Subject: Re: some information theory (very long plus 72K attchmt)
Date: Thu, 21 Oct 1999 11:56:34 -0500
Anton Stiglic <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Say that Comp() is the compression function used
> and P the set of plaintexts of the algo.
>
> It's not hard to work on p's that are in P, and then
> compute Comp(p) to verify the encryption., if you are
> using some sort of languare statistic attack.
Remember that you're working from P, encryption algo and comp algo only.
> If you are using more of a brute force attack,
> and Comp() takes time to compute, you simple brute force on
> the set IC = Image (Comp(P)), this set is much smaller
> then P, so more convinient.
> There is no gain in compressing before, other than the
> fact that it let's you send out smaller chunks of data!
uih? a compression result is NOT always smaller than the uncompressed data
no matter how good your compression scheme is. what do you mean "chunk of
data"? The size of block is always the same.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: some information theory (very long plus 72K attchmt)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 21 Oct 1999 16:50:21 GMT
Anton Stiglic <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Anton Stiglic <[EMAIL PROTECTED]> wrote:
:> [about a post of mine relating to compression (and Tom's notions about it)]
:>
:> : The thing is that in practice, and attacker *does* have the
:> : decompressor at hand. So compressing doesn't help information
:> : theoreticaly wise.
:>
:> Compression helps against all sorts of cryptoanalytic attacks by:
:>
:> A) reducing the quantity of the cyphertext available and,
:> B) removing statistical characteristics present in the compressed
:> plaintext by raising its entropy
: The statistical characteristics are not hidden when you compress.
Oh yes they are ;-)
: If I'm looking for 'e' for example, I just look for Comp('e') instread,
Most compression algorithms do not work by compressing individual
letters. They work (partly) by removing repeated information across
potentially large regions of the file.
Even accepting such a primitive notion about compression, your conclusion
still does not follow.
Even a compression method where such an 'e' -> Comp('e') map existed -
e.g. one which simply knocked off the top bit of each ASCII byte of text
text would still help with security. If the cryptanalyst knows every 8th
bit of the plaintext, this can provide him with concrete information about
how to crack the cypher.
Say the cypher is a stream cypher using an LCG as a PRNG. A relatively
small number of bits allows this type of PRNG to be cracked. The
knowledge of every 8th bit would be enough to break the cypher with
relatively little plaintext. This attack would not work if the top bits
had been removed.
: The quantity of ciphertext does not change either, the lenght of
: the ciphertext yes.
If I was to use both terms, I would use length of the cyphertext and
quantity of the cyphertext synonymously.
: But that doesn't help because.
Because what? The widely accepted notion that providing cyphertext
unnecessarily to your opponent is a bad idea is somehow wrong?
: I'll ask anyone who says that it affects the entropy, to start by giving
: me a mathematical definition of entropy, then we can talk. [...]
This seems to be fair enough - and perhaps I need to qualify my asserion
that compressed messages have greater entropy.
I mean that they have greater entropy per bit present in the message.
Entropy is a measure of the information present in the message. For a
precise mathematical definition see, for example, the "Determination of
bits of entropy" section in ftp://ftp.clark.net/pub/cme/P1363/ranno.html
I'm using entropy as a property of a source, rather than a property of
a string, so if dealing with a string, you need to divide by its length.
This quantity is sometimes called "entropy rate" in an attempt to avoid
confusion. I hope this clarifies what I am talking about.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Umbilical cord: baby bungee.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: some information theory (very long plus 72K attchmt)
Date: Thu, 21 Oct 1999 13:54:55 -0400
Belldandy wrote:
> Anton Stiglic <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > Say that Comp() is the compression function used
> > and P the set of plaintexts of the algo.
> >
> > It's not hard to work on p's that are in P, and then
> > compute Comp(p) to verify the encryption., if you are
> > using some sort of languare statistic attack.
>
> Remember that you're working from P, encryption algo and comp algo only.
>
> > If you are using more of a brute force attack,
> > and Comp() takes time to compute, you simple brute force on
> > the set IC = Image (Comp(P)), this set is much smaller
> > then P, so more convinient.
> > There is no gain in compressing before, other than the
> > fact that it let's you send out smaller chunks of data!
>
> uih? a compression result is NOT always smaller than the uncompressed data
> no matter how good your compression scheme is. what do you mean "chunk of
> data"? The size of block is always the same.
If your set is all the set S is the set off all possible concatenation of
caracters, then
of cours Img(Comp()) is not smaller. If we are working on a set
P of phrases that make sens in english, and that your compression function
works good
on that, your set can be smaller (this is what you guys have assumed in
argument 1 of
your 2 arguments..). Even better if you agree that it doesn't always produce
a smaller set,
argument 1 is then trivialy invalid, it doesn't reduce the lenght of
plaintext to work with.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: some information theory (very long plus 72K attchmt)
Date: 21 Oct 1999 13:18:39 -0400
In article <[EMAIL PROTECTED]>, Anton Stiglic <[EMAIL PROTECTED]> wrote:
>Tim Tyler wrote:
>
>> Anton Stiglic <[EMAIL PROTECTED]> wrote:
>>
>> [about a post of mine relating to compression (and Tom's notions about it)]
>>
>> : The thing is that in practice, and attacker *does* have the
>> : decompressor at hand. So compressing doesn't help information
>> : theoreticaly wise.
>>
>> Compression helps against all sorts of cryptoanalytic attacks by:
>>
>> A) reducing the quantity of the cyphertext available and,
>> B) removing statistical characteristics present in the compressed
>> plaintext by raising its entropy
>
>The statistical characteristics are not hidden when you compress.
>If I'm looking for 'e' for example, I just look for Comp('e') instread,
Comp('e') may not exist (uniquely) -- more accurately, Comp('e') is
not necessarily a substring of Comp('ed'). Thus you can't *find*
all the 'e's in a well-compressed file.
-kitten
------------------------------
** 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
******************************
