Cryptography-Digest Digest #22, Volume #10 Tue, 10 Aug 99 10:13:05 EDT
Contents:
Re: Infallible authentication scheme (David P Jablon)
Re: Ways to steal cookies in HTTP and HTTPS ([EMAIL PROTECTED])
Re: Infallible authentication scheme (David P Jablon)
Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . . (Bruce Wheeler)
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: Error in Counterpane test vectors for Blowfish ([EMAIL PROTECTED])
Re: what is a single cycle sbox ([EMAIL PROTECTED])
What's first? (Gabriel Belingueres)
Re: AES finalists to be announced (SCOTT19U.ZIP_GUY)
Re: What's first? ([EMAIL PROTECTED])
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: Academic vs Industrial (SCOTT19U.ZIP_GUY)
encryption device 1.6GgB/sec Ancort ("Ancort")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: Infallible authentication scheme
Date: Tue, 10 Aug 1999 07:35:19 GMT
All challenge/hashed-response password protocols are woefully obsolete.
Newer protocols are not vulnerable to network dictionary attack,
including a few simple versions of password-authenticated
Diffie-Hellman exchange, including SPEKE, EKE, and SRP.
Full information is at <http://www.integritysciences.com>.
In article <[EMAIL PROTECTED]>,
Eric Lee Green <[EMAIL PROTECTED]> wrote:
>Michelle Davis wrote:
>> Of course, you're right. But since the security requirements of the
>> scheme are extreme, there is the possibility that someone will try to
>> utilise known elements in the string to be hashed (in your example,
>> A||R||I) to facilitate a dictionary attack (a dictionary attack tasked
>> at getting back to the hash input from the MD, and discovering your
>> secret key A).
>
>Err, if you are using a plain text password as your sole source of
>entropy, you are of course correct -- there isn't enough entropy to
>produce a strong hash resistant to dictionary attacks. That's why you
>should not use a plain text password as your sole source of entropy. See
>http://www.counterpane.com for more info on that. Use a key generated
>by a strong (high entropy) key generation mechanism. The hard part then
>becomes the authentication key distribution mechanism and protecting
>that mechanism against hackers (grin). Different topic, far harder than
>this one...
>
>I'm assuming that SHA1 has similar characteristics, except maybe being
>faster than MD5 (?).
SHA1 is a little slower. But hash performance is insignificant in
this application.
======================================================
David P. Jablon
Integrity Sciences, Inc.
[EMAIL PROTECTED]
<http://www.IntegritySciences.com>
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.infosystems.www.misc,comp.security.misc
Subject: Re: Ways to steal cookies in HTTP and HTTPS
Date: Tue, 10 Aug 1999 08:19:55 GMT
In article <7o84ts$f91$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> ...
> [ lots of stuff deleted ]
> ...
>
> Stealing HTTPS Cookies
> ----------------------
>
> By definition, HTTPS cookies are never sent without SSL protection.
> However, variants of our attack to steal HTTP cookies could be
> designed to exploit SSL weaknesses.
>
> Suppose your Widget Store E-Commerce cookie is secure and its server
> supports 128-bit encryption. On the other hand, suppose that Al's
> Shitty Mortgage Company supports only 40-bit encryption and only SSL
> version 2. You don't like 40-bit SSLv2, but you are willing to drop
> your guard temporarily in order to connect to Shitty Mortgage and get
> Al's latest interest rate.
>
>...
> The following attack combines our HTTP cookie
> stealing with the well-known ciphersuite rollback attack (see [WS96])
> in which an SSLv2 session is forced into 40-bit mode. The attacker
> actively acquires the desired cookie encrypted with an unknown 40-bit
> key. After a couple hours of exhaustive search, the plaintext cookie
> is recovered.
>
Appendix E.2 of SSL 3.0 [http://home.netscape.com/eng/ssl3/4-APPN.HTM#E
] describes a procedure that is supposed to foil downgrading of SSL 3.0
connections to SSL 2.0 whereupon they can be attacked. Assuming that SSL
3.0 browsers and servers correctly implement this, it appears to me that
this attack is not possible.
BTW, interesting article.
Cheers,
F.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: Infallible authentication scheme
Date: Tue, 10 Aug 1999 07:58:21 GMT
>In article
><[EMAIL PROTECTED]>,
> Eric Lee Green <[EMAIL PROTECTED]> wrote:
>
>> Err, if you are using a plain text password as your sole source of
>> entropy, you are of course correct -- there isn't enough entropy to
>> produce a strong hash resistant to dictionary attacks.
>> [...] The hard part then
>> becomes the authentication key distribution mechanism and protecting
>> that mechanism against hackers (grin). [...]
Not so hard. Several forms of password-authenticated Diffie-Hellman are
easy and effective. SPEKE, EKE, and SRP are described at
www.integritysciences.com.
>That's why you salt a hash (nothing new here). If you use a it as an
>interactive protocal you get
>
>1. Make a random R and increment I
>2. Send H(K || R || I)
>3. Goto 1 as required
>
>Where R is a random integer and I is an binary counter. I dunno if you
>really need R but it adds entropy to the hash (which I find a good
>idea).
Yep. Nothing new here. If you're trying to describe an
authentication protocol, its broken when R is part of the challenge.
Anyone with access to R and I can perform a brute-force
attack on a low entropy K. The "entropy" in R and I do
not increase the work factor when they are known values.
>> I'm assuming that SHA1 has similar characteristics, [...]
>
>Well collisions have been found in MD5 whether they are exploitable is
>another thing. In this situtation I would say no becuase the attacker
>is forced to use only one side of
>
>H(K || R || I) = H(K' || R || I)
Hash strength is an insignificant issue compared to the
fact that Eve can perform an unlimited off-line attack
using the above test with any dictionary of K' = {K1, K2, ...}.
======================================================
David P. Jablon
Integrity Sciences, Inc.
[EMAIL PROTECTED]
<http://www.IntegritySciences.com>
------------------------------
From: [EMAIL PROTECTED] (Bruce Wheeler)
Crossposted-To: comp.lang.c++
Subject: Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . .
Date: Tue, 10 Aug 1999 09:03:52 GMT
On Mon, 09 Aug 1999 16:49:56 +0600, Pretty Boy Mohandas <[EMAIL PROTECTED]>
wrote:
[snip]
>The reader was better too--you could set up the background color
>to something other than glaring white.
>--
>len
>if you must email, reply to:
>len bel at world net dot att dot net (no spaces, ats2@, dots2.)
Very off-topic here, but you can change it in the 'accessibility' options
under IE4. Apparently, we're visually handicapped if we want to customize
our envirnoments.
Note, however, this is a global change for IE, not just for InfoViewer.
Doesn't work for IE3, and I haven't looked at IE5.
'Control Panel' - 'Internet' - 'Accessibility' - 'Ignore colors specified
on Web pages'.
Then set default window background to something pleasant, under Control
Panel - Display Properties. Again global, for everything in Windows.
Regards,
Bruce Wheeler
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Tue, 10 Aug 1999 11:41:59 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bruce Schneier) wrote:
> The envelope, please... The five AES finalists are Mars, RC6,
> Rijndael, Serpent, and Twofish.
eegad. How did MARS make it? It's gross complex and ugly. The rest of
the candidates I agree with.
I think though like many have said AES should be a family of
algorithms. One should be able to pick 'fast' but modestly less secure
(say work factor off by a couple factors). And 'slow' but secure for
the keysize picked. Also good smartcard and hardware ciphers should be
part of AES. If a cipher is not good for some of the departments why
put it there?
Personally I think the top two ciphers should be RC6 and Twofish. My
rational is that RC6 is simple and based on the design principles of
RC5. Although 'fixed-points' have been found in the quadratic function
I don't see that as a security compromise. Twofish was just designed
by some really smart people. I trust their ability, plus Twofish is
rather efficient and compact. Both are suitable for hardware as well
as smartcards as well as popular x86 type computers which dominate the
market.
Good luck Twofish and RC6 teams!!!
Tom
--
PGP 6.0.2i 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: Error in Counterpane test vectors for Blowfish
Date: Tue, 10 Aug 1999 11:45:28 GMT
In article <7oo0sa$1k68$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> I thought Mr B.S. himself wrote blowfish and he told you to
> ask here about test vectors. Why does this sound fishy?
They are probably available online.
Blowfish is really hard to get wrong though... It's just
for r = 0 to 15
A xor P[r]
B xor F(B)
(B, A) = (A, B)
next r
You could generate the sboxes any way you want (for example take 33
byte keys (32 byte key + checksum) and do a lagged fibonacci ...).
Tom
--
PGP 6.0.2i 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: what is a single cycle sbox
Date: Tue, 10 Aug 1999 11:50:00 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> Yes, but it means more than that: during the 2^n times, you never get
the same
> substitute twice.
Then you wouldn't be able to step it 2^n times before ending where you
started.
> It limits the keyspace, but it does in a sense restrict the S-box
to "nice"
> values. Short cycles in an S-box can, under certain circumstances, be
a
> weakness.
I noticed that the sbox in RC2/MD2 is not single cycle. Has that
contributed to a weakness?
I agree that no element { GF(2^n) should belong to a sub-group to avoid
fixed points. However most of the time this is not a requirement. Not
blowfish/cast sboxes are not single cycle (or not part of the design).
because they use random round keys (avoid fixed points) and sboxes as
part of a mixing function. There still can be fixed points but the
round keys should prevent that in 99.9% of all cases.
Tom
--
PGP 6.0.2i 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: Gabriel Belingueres <[EMAIL PROTECTED]>
Subject: What's first?
Date: Tue, 10 Aug 1999 11:56:56 GMT
Hi,
I was wondering why is that when I send a ciphered message, I have to do
the MAC computation from the plaintext, then the encryption of the
plaintext + MAC.
If I would do this in the reverse order (ie encrypt first, then compute
the MAC from the ciphertext) I could save a decryption when the message
is modified.
I think the two schemes provide the same security, but the
former provides more overhead. However, it is used in SSL.
Does anybody knows why it is done always this way?
Thanks,
Gabriel.
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: AES finalists to be announced
Date: Tue, 10 Aug 1999 13:47:19 GMT
In article <7oo2rs$147u$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
>>If they allowed anyone
>>to enter with a TEXT file listing instead of PS then I would have been in.
>
>The fact that you couldn't figure out how to produce a postscript file in
>1998 does not give me confidence in your ability to produce a decent cipher.
>
I did want to produce postscript file. I felt it was a very good sign that
it was a phony cintest to begin with.
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: What's first?
Date: Tue, 10 Aug 1999 12:52:35 GMT
In article <7op424$5rj$[EMAIL PROTECTED]>,
Gabriel Belingueres <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I was wondering why is that when I send a ciphered message, I have to
do
> the MAC computation from the plaintext, then the encryption of the
> plaintext + MAC.
>
> If I would do this in the reverse order (ie encrypt first, then
compute
> the MAC from the ciphertext) I could save a decryption when the
message
> is modified.
>
> I think the two schemes provide the same security, but the
> former provides more overhead. However, it is used in SSL.
>
> Does anybody knows why it is done always this way?
>
> Thanks,
> Gabriel.
A MAC should be a one-way keyed function of the plaintext to avoid
giving out known plaintext. Simple as that. The CBC MAC gives out
known plaintext with every message but is rather efficient to compute.
Personally I would just hash the plaintext then encrypt the hash, also
I would change the key with every message (possibly with a salt).
Tom
--
PGP 6.0.2i 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: Tue, 10 Aug 1999 12:23:51 GMT
In article <7op365$5ct$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Bruce Schneier) wrote:
> > The envelope, please... The five AES finalists are Mars, RC6,
> > Rijndael, Serpent, and Twofish.
>
> eegad. How did MARS make it? It's gross complex and ugly. The rest
of
> the candidates I agree with.
I think MARS made it for a few reasons.
1. If I remember correctly, it is one of the faster ciphers available.
Smart cards may be an exception.
2. I forget where I read it, but apparently it uses just about every
trick in the book to make it secure.
3. This is what I like most about the cipher, the layaring of rounds.
MARS has three layars, forward mixing, cryptographic core, and backwards
mixing. The mixing of structures was done to prevent certain types of
analysis that bypass the first few rounds. (I hope I quoted this
correctly from IBM) Also, it should make any analysis harder to break
it.
As for ugly, I though it was very nice actually. IBM explained
everything very well in there proposal and it all seems to make very
good sense.
>
> I think though like many have said AES should be a family of
> algorithms. One should be able to pick 'fast' but modestly less
secure
> (say work factor off by a couple factors). And 'slow' but secure for
> the keysize picked. Also good smartcard and hardware ciphers should be
> part of AES. If a cipher is not good for some of the departments why
> put it there?
>
> Personally I think the top two ciphers should be RC6 and Twofish. My
I think RC6 is one of the top ciphers on everybody's list. The ciphers
I was most impressed with were
1. RC6
2. MARS
3. Rijndeal
4. Twofish
Which one will win, I don't know. If I wanted a family, those would be
the four I'd want.
> rational is that RC6 is simple and based on the design principles of
> RC5. Although 'fixed-points' have been found in the quadratic
function
> I don't see that as a security compromise. Twofish was just designed
> by some really smart people. I trust their ability, plus Twofish is
> rather efficient and compact. Both are suitable for hardware as well
> as smartcards as well as popular x86 type computers which dominate the
> market.
>
> Good luck Twofish and RC6 teams!!!
>
> Tom
> --
> PGP 6.0.2i 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.
>
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: Tue, 10 Aug 1999 12:49:30 GMT
In article <7op5ke$711$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I think MARS made it for a few reasons.
>
> 1. If I remember correctly, it is one of the faster ciphers available.
> Smart cards may be an exception.
RC6 and Twofish are very fast on x86 computers as well. Both at about
18 cycles/byte (well I think RC6 is a tad slower).
> 2. I forget where I read it, but apparently it uses just about every
> trick in the book to make it secure.
That doesn't mean a thing.
> 3. This is what I like most about the cipher, the layaring of rounds.
> MARS has three layars, forward mixing, cryptographic core, and
backwards
> mixing. The mixing of structures was done to prevent certain types of
> analysis that bypass the first few rounds. (I hope I quoted this
> correctly from IBM) Also, it should make any analysis harder to break
> it.
Well that is true. but if there are weaknesses in either
forward/backward mixing phase then it's not. Technically both RC6 and
Twofish have three layers each as well. They both have a pre-white,
mixing then a post-white. The pre/post white in Twofish is more
complete though (all of the input is whiten).
> As for ugly, I though it was very nice actually. IBM explained
> everything very well in there proposal and it all seems to make very
> good sense.
Maybe but it's still rather complex as compared to RC6. Good
algorithms don't need to be complicated. Twofish is more complicated
then RC6 but any competent security professional should be able to code
it. (I haven't tried so I don't know).
> I think RC6 is one of the top ciphers on everybody's list. The
ciphers
> I was most impressed with were
> 1. RC6
> 2. MARS
> 3. Rijndeal
> 4. Twofish
>
> Which one will win, I don't know. If I wanted a family, those would
be
> the four I'd want.
Well I still think if anything RC6 and Twofish should be at the top of
the list. Not that I don't trust MARS though. Rijndael seems quite
secure and compact. I haven't really looked at it but I would put it
among the top 4 as well.
Tom
--
PGP 6.0.2i 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: Academic vs Industrial
Date: Tue, 10 Aug 1999 14:16:22 GMT
In article <7ooh07$r0v$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
>In article <7oo989$515$[EMAIL PROTECTED]>,
>David A Molnar <[EMAIL PROTECTED]> wrote:
>> Other naive question : I was under the impression that random S-boxes were
>> likely to be weak against differential cryptanalysis. Do key-dependent
>> S-boxes escape this problem b/c they're secret, or are there ways to
>> infer their structure from some attack?
>
>If you're not careful, random S-boxes can be problematic, even if they're
>secret.
>
>This is especially true if the S-boxes are very small. For example, random
>S-boxes are very bad for DES.
>
>Remember that not all key-dependent S-boxes are what you call "random"
>("random" = generated uniformly from the set of all S-boxes). You can
>try to generate key-dependent S-boxes that avoid the weak choices.
>
>See, e.g., Twofish for a technique for generating key-dependent S-boxes
>that seems to work.
>
>(Actually, another way of viewing Twofish's S-boxes is as a mini 8-bit
>keyed cipher whose structure is unkeyed. Thus, you can think of Twofish
>as using either key-dependent or key-independent S-boxes, whichever you
>prefer -- both views are equally valid.)
Actually the so called S-boxes in 2-fish are quite small and of a very
limited size. If you want vastly larger 'more secure" key-dependent S-boxes
think of scott19u the S-boxes used are the complete class of single cycle
S-boxes and not even the Slide Attack of Wagners can make a dent in the
security of such a type of method.
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: "Ancort" <[EMAIL PROTECTED]>
Subject: encryption device 1.6GgB/sec Ancort
Date: Tue, 10 Aug 1999 18:21:05 +0400
The third phase of modelling of the encryption devices with speed of 1.6
GgB/sec
is over with success.
Our site www.ancort.ru
------------------------------
** 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
******************************
