Cryptography-Digest Digest #630, Volume #14 Sat, 16 Jun 01 12:13:01 EDT
Contents:
Re: Tell me could this one-way function be somewhat secure (wtshaw)
Re: hello? (wtshaw)
SSL/TLS compression methods??? ("Ricardo")
Re: Tell me could this one-way function be somewhat secure (Tim Tyler)
Re: taking your PC in for repair? WARNING: What will they find? (nemo outis)
Re: CipherText E-mail encryption ("Prichard, Chuck")
Re: Is ECB truly more secure than CBC? (John Savard)
correlation immunity question ("Tom St Denis")
Re: SSL/TLS compression methods??? (Erwann ABALEA)
Re: Is ECB truly more secure than CBC? (SCOTT19U.ZIP_GUY)
Re: FIPS 140-1 test (Peter Gutmann)
Re: Is ECB truly more secure than CBC? ("Tom St Denis")
Re: Bow before your new master ("Harris Georgiou")
Re: CipherText E-mail encryption ("Prichard, Chuck")
Re: Is ECB truly more secure than CBC? (David Hopwood)
Help with error correction (63,48) code (Alexander Popov)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Tell me could this one-way function be somewhat secure
Date: Sat, 16 Jun 2001 07:01:12 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> Well, you *will* if you hash material with more entropy that the width of
> the combined hash. A scarcity of source material appears to be why
> Marko's example failed to demonstrate this.
> --
But, anyone should know that brief input that is extrapolated into a
longer so-called hash is merely an exercise in super-redundancy and low if
not marginal security. And, using a fixed hash with outputs much shorter
than the input guarantees a generous surplus of collisions. There is no
short cut to using a pleasantly long and obscure input string and a
suitable function that can handle it in its length.
I suggest that two less intelligent hashes can do wonders if combined, one
which closely tracks the size of the input in output, and some wildly
different hash, perhaps more of a digest, to cut effective collisions way
down.
--
In trying to get meaning from the TmV-OK saga, remember that
those who do not learn from history are apt to repeat it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: hello?
Date: Sat, 16 Jun 2001 07:16:46 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> > Tom St Denis
> There is just too much of you around this board.
Never is it so when someone pursues an intellectual passion to learn and
expand what all might know. In spite of ups and downs, as crypto is why
many are here, the rest of life can often merely be a distraction. The
field deals with the supreme essence of ultimate knowledge, knowing what
others cannot, and preserving uniqueness, preserving individual
superiority in a personal kingdom. If bored....no, the true zealot is
never bored as defeat directs one to realization and can spur activity in
new directions.
--
In trying to get meaning from the TmV-OK saga, remember that
those who do not learn from history are apt to repeat it.
------------------------------
From: "Ricardo" <[EMAIL PROTECTED]>
Subject: SSL/TLS compression methods???
Date: Sat, 16 Jun 2001 15:49:35 +0200
Hi,
1) Does anyone know which compression methods are used in SSLv3 and TLSv1?
(I only know two: gzip and zip)
2) For each compression-method values are used in the handshake-messages
from the
client and the server. Has anyone got an idea which value belongs to which
compression-
method? (In the book of E.Rescorla "SSL and TLS, Designing and Building
Secure Systems"
and in the drafts of Netscape nothing was said about which compression and
which values
are used for the compressions.)
Thx.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Tell me could this one-way function be somewhat secure
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Jun 2001 13:44:55 GMT
wtshaw <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
:> Well, you *will* if you hash material with more entropy that the width of
:> the combined hash. A scarcity of source material appears to be why
:> Marko's example failed to demonstrate this.
: But, anyone should know that brief input that is extrapolated into a
: longer so-called hash is merely an exercise in super-redundancy and low if
: not marginal security.
Does anyone "know" that?
: I suggest that two less intelligent hashes can do wonders if combined, one
: which closely tracks the size of the input in output, and some wildly
: different hash, perhaps more of a digest, to cut effective collisions way
: down.
It sounds like you would create collisions in the former by considering
plaintexts of the same size. Then you only have the latter "less
intelligent" hash to deal with.
I think I'd rather take an ordinary hash of their combined size.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
Crossposted-To:
alt.privacy,alt.security.pgp,alt.security.scramdisk,alt.privacy.anon-server
From: [EMAIL PROTECTED] (nemo outis)
Subject: Re: taking your PC in for repair? WARNING: What will they find?
Date: Sat, 16 Jun 2001 14:02:46 GMT
Not only could it be a Trojan - one could speculate that its "random
overwrite pattern" was actually an encrypted version of the original contents!
They could then sell the decryption key to LE!
Regards,
PS When I go paranoid, I don't do it by halves :-)
In article <[EMAIL PROTECTED]>, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote:
>P.Dulles wrote:
>>
>> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>> says...
>> >: P.Dulles wrote:
>> >: <SNIP>
>> >:
>> >: add
>> >:
>> >: 12. What does EE do to twart Proxies and remote monitoring software?
>>
>> Excellent point. But they won't answer. I also forgot to mention that
>> a trojan could also be installed on your system by your boss or the
>> police, and they can retrieve all files that way.
>
>For that matter, EE could *be* a trojan. How do we know it isn't?
>
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Sat, 16 Jun 2001 14:03:03 GMT
CipherText's are one way messages.
In Outlook Express they can be opened and Javascript is able to link to a
URL opening a Browser session to download content. I suppose the request
could contain the key variable.
The problem with Eve's scheme that I see is that the message in Bob's
file of messages contains the smoking gun: Eve's URL and the proof that a
crime was deliberately attempted. Prosecuting the crimminal charge would
focus on proving that Eve is the real perpetrator. Substantiating that
she is in the first place capable would probably not be difficult.
Eve is infringing on the privacy of the CipherText users Bob and Alice
and has no right to alter the CipherText product to make her intrusions
on Bob and Alice. She is breaking at least one federal communications law
as well. The criminal offense carries a penalty and the civil damages
that could be sought by Bob, Alice and CipherText could be considerable.
The main problem I see here is that it is the sort of crime that teenage
computerists would be engaged in. Fairly easy to pull off. To get any
real benefit of having stolen the password, it would be necessary to gain
access to Alice and Bob's messages. You are suggesting that in many
applications, this would be the first step in some kind of espionage
against the parties of Bob and Alice.
I think leaving the proof on Bob's computer is a little sloppy, but I see
the need for detection of an alterred document.
Looking back to the originator, I see Eve who is pretending to be Alice
without her password. Bob would know that something is wrong because when
he enterred the password, the message would not be decrypted. His
response would be to immediately reply to Alice.
The plan might work to capture messages, if they were previously stolen
from Bob's computer by Eve.
Very interesting...
-C. Prichard
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is ECB truly more secure than CBC?
Date: Sat, 16 Jun 2001 14:06:26 GMT
On Fri, 15 Jun 2001 23:12:21 +0000 (UTC), [EMAIL PROTECTED]
(David Wagner) wrote, in part:
>In my opinion, it would be absurd to use ECB mode. CBC mode is just fine.
I agree with that, but Joseph Atwood was not claiming ECB mode was
better. He just came up with a contrived theoretical scenario
illustrating a very unusual circumstance in which ECB would have one
advantage over CBC mode. On this basis, he argued only for retaining
ECB mode as an option, not for preferring it to CBC mode.
His mathematics are valid, so this is an interesting argument
highlighting the fact that we "don't know everything" about what makes
ciphers secure just yet. It in fact also highlights a problem with the
current favored mode of reasoning about ciphers - looking for
theoretical academic weaknesses, because even the poor ciphers are too
strong to find actual practical breaks. What if you can't avoid a
theoretical weakness, no matter which way you turn?
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: correlation immunity question
Date: Sat, 16 Jun 2001 14:09:31 GMT
I'm reading up the older correlation immunity papers from eurocrypt. I've
noted a tendency to attack system that have multiple LFSR's that are clocked
once and fed into a nonlinear function.
What if a single LFSR was used and clocked many times. Wouldn't that be
slightly harder to attack [I wouldn't imagine by much]?
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: Erwann ABALEA <[EMAIL PROTECTED]>
Subject: Re: SSL/TLS compression methods???
Date: Sat, 16 Jun 2001 16:29:20 +0200
On Sat, 16 Jun 2001, Ricardo wrote:
> 1) Does anyone know which compression methods are used in SSLv3 and TLSv1?
> (I only know two: gzip and zip)
I think that no compression method is really defined. Compression can be
enabled by the SSL and TLS standards, but the real mechanisms will be
defined latter (in a future version).
By this time, you could could implement your own compression algorithms
(or use the zlib for this purpose), but you won't be interoperable with
other SSL-enabled products. It's OK if you write both the client and the
server, and they only need to talk each one to each other and no one else.
--
Erwann ABALEA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Is ECB truly more secure than CBC?
Date: 16 Jun 2001 14:30:58 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On Fri, 15 Jun 2001 23:12:21 +0000 (UTC), [EMAIL PROTECTED]
>(David Wagner) wrote, in part:
>
>>In my opinion, it would be absurd to use ECB mode. CBC mode is just
>>fine.
>
>I agree with that, but Joseph Atwood was not claiming ECB mode was
>better. He just came up with a contrived theoretical scenario
>illustrating a very unusual circumstance in which ECB would have one
>advantage over CBC mode. On this basis, he argued only for retaining
>ECB mode as an option, not for preferring it to CBC mode.
>
>His mathematics are valid, so this is an interesting argument
>highlighting the fact that we "don't know everything" about what makes
>ciphers secure just yet. It in fact also highlights a problem with the
>current favored mode of reasoning about ciphers - looking for
>theoretical academic weaknesses, because even the poor ciphers are too
>strong to find actual practical breaks. What if you can't avoid a
>theoretical weakness, no matter which way you turn?
>
Then I guess you go down the same path the CTR advicates go.
Which is to pretend your underlying cipher is totally secure.
And then give false proofs pretending that your weak chainning
mode is very secure. When one uses false premises its easy to
come to false conculsions. Wagner is correct the CTR proofs don't
worry about lengths. It may be why he was afraid to enter the
very long thread about "perfect security". Many people having
read BS crypto books where under the false conclusion that a
OTP for many message of varying length would be used only to
the lentgh of any sent message. There people thought they
still had perfect security. They did not even though a OTP
was used. Tim and I aruged for many many messages yet Wgner
failed to make an appearance and let the herd be misled.
It the same with security of CTR versuses other modes like
CBC. CTR is weaker and I am sure if he was honest he would
admit it. I am not saying to drop CTR mode I just feel it
false to put it in the same secuity level as CBC. Which
still is far less secure than 3 rounds of "wrapped PCBC"
something Mr Wagner would never advicate.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: FIPS 140-1 test
Date: Sat, 16 Jun 2001 15:07:27 -0000
Tim Tyler <[EMAIL PROTECTED]> writes:
>Dobs <[EMAIL PROTECTED]> wrote:
>: I am looking for source code of FIPS 140-1 statistical test for randomness
>: which is used for high security application (that's what was written in
>: Handbook of Applied Cryptography:)
>It's at: http://quartus.net/files/Misc/
>Docs at: http://www.cerberussystems.com/INFOSEC/stds/fip140-1.htm
As a followup question, has anyone ever looked at doing the tests which
require an FPU in an (admittedly approximate) integer-only way? There are
some embedded systems which don't do FP-maths too well.
Peter (who hacked together a crude approximation, but was too lazy to spend
too much time on it :-).
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Sat, 16 Jun 2001 15:09:23 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (John Savard) wrote in
> <[EMAIL PROTECTED]>:
>
> >On Fri, 15 Jun 2001 23:12:21 +0000 (UTC), [EMAIL PROTECTED]
> >(David Wagner) wrote, in part:
> >
> >>In my opinion, it would be absurd to use ECB mode. CBC mode is just
> >>fine.
> >
> >I agree with that, but Joseph Atwood was not claiming ECB mode was
> >better. He just came up with a contrived theoretical scenario
> >illustrating a very unusual circumstance in which ECB would have one
> >advantage over CBC mode. On this basis, he argued only for retaining
> >ECB mode as an option, not for preferring it to CBC mode.
> >
> >His mathematics are valid, so this is an interesting argument
> >highlighting the fact that we "don't know everything" about what makes
> >ciphers secure just yet. It in fact also highlights a problem with the
> >current favored mode of reasoning about ciphers - looking for
> >theoretical academic weaknesses, because even the poor ciphers are too
> >strong to find actual practical breaks. What if you can't avoid a
> >theoretical weakness, no matter which way you turn?
> >
>
> Then I guess you go down the same path the CTR advicates go.
> Which is to pretend your underlying cipher is totally secure.
That a requirement though. Think about it. If your cipher is say totally
linear then even the glorious praise-jesus BICOM mode of operation cannot
save it.
Therefore it makes sense to work from the assumption that the cipher is
secure.
> And then give false proofs pretending that your weak chainning
> mode is very secure. When one uses false premises its easy to
> come to false conculsions. Wagner is correct the CTR proofs don't
> worry about lengths. It may be why he was afraid to enter the
> very long thread about "perfect security". Many people having
> read BS crypto books where under the false conclusion that a
> OTP for many message of varying length would be used only to
> the lentgh of any sent message. There people thought they
> still had perfect security. They did not even though a OTP
> was used. Tim and I aruged for many many messages yet Wgner
> failed to make an appearance and let the herd be misled.
> It the same with security of CTR versuses other modes like
> CBC. CTR is weaker and I am sure if he was honest he would
> admit it. I am not saying to drop CTR mode I just feel it
> false to put it in the same secuity level as CBC. Which
> still is far less secure than 3 rounds of "wrapped PCBC"
> something Mr Wagner would never advicate.
Give me three reasons why CTR is weaker than wrapped PCBC mode and I will
give you three reasons why PCBC mode is weaker than CBC mode [and seven more
as to why CTR is more efficient].
"X stronger than Y" is meaningless gibberish crap.
"X stronger than Y wrt to Z" is meaning ful. For example, PCBC mode has
one-way diffusion, a little better in wrapped mode. What if the message is
say 2^32 blocks long? It is possible that the diffusion will be less than
desirable., etc...
Tom
------------------------------
From: "Harris Georgiou" <[EMAIL PROTECTED]>
Subject: Re: Bow before your new master
Date: Sat, 16 Jun 2001 18:16:14 +0300
Ï Jschutkeker <[EMAIL PROTECTED]> Ýãñáøå óôï ìÞíõìá óõæÞôçóçò:
[EMAIL PROTECTED]
> Think this guy should get some professional help...?
Noway....he's gone into hyperspace.....what a waste....
--
Harris
- 'Malo e lelei ki he pongipongi!'
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Sat, 16 Jun 2001 15:19:39 GMT
Alice's participation in the civil lawsuit would be based on whether it
was substantiated by the evidence obtained in the search of Eve's
premise's that Eve was in possession of any messages sent by Alice.
There are implications about the possible gap in security regarding how
the CipherText service could be manipulated by employees of the internet
service provider and law enforcement officials conspiring to illegally
obtain access to private records of an individual or corporation.
CipherText would be very quick to press charges on such a case of
infringement on its public image.
-C. Prichard
------------------------------
Date: Sat, 16 Jun 2001 01:02:03 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
=====BEGIN PGP SIGNED MESSAGE=====
lcs Mixmaster Remailer wrote:
> Someone named Joseph Ashwood is posting to the XML Encryption list,
> presenting himself as a cryptography expert. In his most recent posting
> he offers an argument as to why ECB mode should be supported in addition
> to CBC! Will any respected cryptographers speak up to say that this is
> a credible argument?
It isn't credible. ECB is an insecure mode for most purposes, including
the purposes to which XMLEnc will be put. Whether an artificial situation
can be found where a particular type of attack might work against CBC but
not ECB, for an insecure block cipher, is beside the point.
I haven't been following the XMLEnc standard, but if it does not already
do so, it should support an encryption mode that is non-malleable, i.e.
has the IND-CCA property [BN00]. CBC does not.
[BN00] Mihir Bellare, Chanathip Nampremprey,
"Authenticated Encryption: Relations among notions and analysis of
the generic composition paradigm,"
Preliminary version in Advances in Cryptology - ASIACRYPT '00,
Lecture Notes in Computer Science Vol. 1976 (T. Okamoto ed.),
Springer-Verlag, 2000.
Full version (September 25, 2000) available from
http://www-cse.ucsd.edu/users/mihir/
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOyqhkTkCAxeYt5gVAQG4hQf6AwV4uwpqTi7zjbx6HH08n0HGZMpRPa/t
+cGs4aaITV+Ri+QH8cr5EQA+xU/lRrpP48Z0Dp6ydgOL9lKx529N9XhXnbhOxRbv
+33p2RIT+mYL4QmDKhS+PQFDuWEEwxJSd0Jcc138Vd9AIe7Tipbfq1UMQsNiTK5r
SPNk7QhDwl3P2Efn4FM04LVZ+GtpkMUYVKtNqhO3wYFdRQZ8zo3ttZ7BydNZsEZ5
wEpOFAUnrE6Tm0E4Eayul77w38ytDGo1EbWSRZHel6Vw6miaB6fRWP/IhWMZu6u8
Qd2lDmlEiDEMIfx/G4dEm8GWoYgrCAKJd5X5DA0Lkxe7YDjQyiD8SQ==
=Gjjs
=====END PGP SIGNATURE=====
------------------------------
From: Alexander Popov <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Help with error correction (63,48) code
Date: Sat, 16 Jun 2001 18:57:05 +0300
Dear forum,
I need your help!
I am trying to implement an error correction code over an air
link. The format of the messages is known as MPT1327. The code is
(63,48) with the generating polinomial being:
X15 + X14 + X13 + X11 + X4 + X2 + X0
The last (64th) bit is used for total parity check.
The source code for coding and for calculating the syndwome at
decoding is written. What I need is some information (algorithm,
sources, links) about how to correct the bits when I have the
syndrome. I've heard some things about using Berlekemp's algorithm,
but I don't know what it is all about...
The problem is that I must implement this thing in a
microcontroller with only 8K available for code and 512 bytes of data
memory!
Thank you for any help in advance!
P.S. The algorithms used for coding and calculating the syndrome are
as follows:
CODING
The first 15 check bits are derived from a (63,48) cyclic code by
using codeword bits 1 to 48 as the coefficients X62 to X15 (in that
order) of a 63 bit polynomial, which is then divided modulo-2 by the
generating polynomial;
On completion of the division, the 15 coefficients X14 to X0 of the
remainder are used as the first 15 check bits (codeword bits 49 to
63), with the X0 coefficient (bit 63 of the complete codeword)
inverted.
Finally, bit 64 of the codeword is added to provide an even parity
check of the whole 64-bit codeword.
DECODING
The parity of the received 64-bit codeword is checked, then bit 63 of
the codeword is inverted. The first 63 bits of the resulting codeword
are then used as the coefficients X77 to X15 of a 77 bit polynomial,
which is then divided modulo-2 by the ‘generating polynomial’. If the
remainder is zero, and the parity check is met, then no errors have
been detected.
The 15-bit remainder of this division is used as the least significant
15 bits of the 16-bit ‘Syndrome’ word, while the msb of the Syndrome
word is set to ‘1’ if the parity of the received codeword is
incorrect.
Alexander Popov
SeNa Electronic, R&D HoD
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
