Cryptography-Digest Digest #631, Volume #14 Sat, 16 Jun 01 17:13:01 EDT
Contents:
Re: CipherText E-mail encryption ("Prichard, Chuck")
Re: taking your PC in for repair? WARNING: What will they find? (Loki)
Re: Tell me could this one-way function be somewhat secure (Bill Unruh)
Re: FIPS 140-1 test (Tim Tyler)
Re: Comp Results: Thomas Boschloo FAILS to prove himself, as everyone expected all
along... (Anonymous)
Re: Is ECB truly more secure than CBC? (Tim Tyler)
SRP, PAK-R, Augmented EKE, and Kaliski-Ford Described on Web Site (John Savard)
Re: Is ECB truly more secure than CBC? ("Tom St Denis")
Re: Is ECB truly more secure than CBC? (lcs Mixmaster Remailer)
Re: Is ECB truly more secure than CBC? ("Tom St Denis")
Re: Is ECB truly more secure than CBC? (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: Re: CipherText E-mail encryption
Date: Sat, 16 Jun 2001 16:44:27 GMT
I wonder how big the payoffs are whenever a company like CipherText has
to look the other way in these cases.
-
------------------------------
From: Loki <*@*.org>
Crossposted-To:
alt.privacy,alt.security.pgp,alt.security.scramdisk,alt.privacy.anon-server
Subject: Re: taking your PC in for repair? WARNING: What will they find?
Date: Sat, 16 Jun 2001 17:40:11 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
>: 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?
Well, we don't. EE (Andy) absolutely refuses to provide any independant
testing or verification of his claims, and we have already shot down
most of them.
However, I do believe in being fair, and I have found no indications of
trojan-like behavior or suddenly hidden files on my machine or for that
matter, anything else that would indicate the product to be malicious.
I'm not a code-cruncher, so I can't say whether or not there is a back
door. I will willingly admit that I think it is a good disk utility; I
take serious exception to their pricing, claims, and marketing. For
$40, it was a good - if suspect - product. For $150 anyone who buys it
should see a doctor.
--
Loki
----
The Truth about Evidence Eliminator:
http://badtux.org/eric/editorial/scumbags.html
http://www.radsoft.net/resources/software/reviews/ee/07.htm
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Tell me could this one-way function be somewhat secure
Date: 16 Jun 2001 18:25:48 GMT
In <9gf9lk$181$[EMAIL PROTECTED]> "Marko Lavikainen" <[EMAIL PROTECTED]>
writes:
]> That's much the same as increasing the size of the hash. You'll still get
]> collisions - but not so frequently.
]I was wondering the same. But I still don't know if it is the same thing.
]There must be collisions, at least if there is no size limit for a document,
]but still if the properties of the hash functions are such that they work
]slightly differently.
]For instance, if one would use the size of the document as one variable, the
]hashvalues would grow at different rate as the size of the document grows.
]So, in one way even it is not compeletely true, to find false document,
]which satisfies both hashvalues, the document would be extremely huge, say
]10Gb.
]What I mean is that the hash values goes around and around as document grows
]but they never get same value before the document is inpractically long.
Uh, no. There are too many long documents. The probability is that you will get a
collision every time the document size increases by the length of the hash. Given a
document of length N and a hash of length n, then the number of other documents
with collisions with that same length N is 2^(N-n). Ie, for say a 128 bit hash (16
bytes,) a 1kB document ( 1000 characters, or 150 words) the number of documents
with the same hash and the same size would be about 2^(8000-128) which is a
goodly number.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: FIPS 140-1 test
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Jun 2001 18:23:33 GMT
Peter Gutmann <[EMAIL PROTECTED]> wrote:
: 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.
I'm always after more integer-friendly randomness tests. Chi-squared,
entropy, serial correlation, monte-carlo PI - *many* tests seem to use FP.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
Date: Sat, 16 Jun 2001 20:29:02 +0200
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: Comp Results: Thomas Boschloo FAILS to prove himself, as everyone
expected all along...
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss,alt.privacy.anon-server
On Sun, 06 May 2001, "Thomas J. Boschloo" <[EMAIL PROTECTED]> wrote:
Stop Boschloo posting diarrhea
Boschloo STINKS
Boschloo TOO MUCH
Boschloo NO
Boschloo TOO MUCH
Boschloo is a TROLL
Boschloo is a CLOWN
Against Boschloo
Neuter Boschloo
SCREW Boschloo
Stop Boschloo NUTS
Stop Boschloo NONSENSE
Stop Boschloo RAT
Stop Boschloo insanity
Boschloo is a PLAGUE
NONSENSE from Boschloo, as usual,
trying to occupy frontstage with his pretense of knowledge
HISTORY:
That Boschloo bozo is a clown and a troll who has been looming around for nearly a
year.
Don't mistake a "regular" (troll) with a knowledgeable person: that self-proclaimed
"security expert" is not even a remailer user. In the past, he proved himself unable
to check a PGP signature, and got ridicule from every single technical topic he wanted
to talk about.
Besides false or inaccurate or misleading technical misinformation, his posts are
about his avowed mental illness, or for bashing remops or real freedom fighters: he
likes to quarrel with every one, and stir shit. Sometimes, it is even pure delirium
(when he misses his pills?)
One of his last actions was to stage a hoax about his own suicide, just to try to grab
some sympathy, after he had been exposed as a troll and technically incompetent.
The worst being his teasing of Script-Kiddie until it triggered a new flood on apas.
Of course, he refuses to apologize.
Actually, the level of contempt he shows for remailer users:
they don't give their names, while he does
that can't do anything against him, without giving their names
is in no way different from what is displayed by Pangborn, Burnore and the like
Ignore him completely, killfile him, respect others' killfiles
KILLFILE:
To put him in your killfile, put "Author: Boschloo"
That will make disappear both him and people who warn about him
If you want to tell him to buzz off, or warn about him,
use a nickname containing "Boschloo" (Boschloo Hater, Boschloo Sucks,...)
to accomodate such killfile for "regulars", and still warn newbies
COURAGE:
Boschloo is getting _no_ answer from apas any more.
He has to crosspost to various newsgroups to try to grab some attention.
In a few months, it will be gone.
Stop Boschloo diarrhea
Stop Boschloo posting diarrhea
Fight Boschloo
Stop Boschloo MADNESS
Stop Boschloo RAT
Stop Boschloo INSANITY
Stop Boschloo NONSENSE
Stop Boschloo NUTS
Boschloo TOO MUCH
Boschloo is a PLAGUE
SCREW Boschloo
Neuter Boschloo
Boschloo is a CLOWN
Boschloo TOO MUCH
Stop Boschloo posting diarrhea
Boschloo STINKS
Boschloo NO
Boschloo PLAGUE
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Jun 2001 18:40:58 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
:> 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.
You can /sometimes/ get a secure system - even if your cypher has a break.
For example, if there's an attack on Rijndael that takes N bytes of
known-plaintext, then compressing the messages so that more of them are
smaller than this is likely to decrease the proportion of them that can
be read using this attack.
I think /some/ paranoia in needed among cryptographers. If you believe
your cypher is secure, that faith may be your undoing.
Of course paranoia can be taken to unhealthy extremes - but one of those
unhealthy extremes appears to be not having any at all.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: SRP, PAK-R, Augmented EKE, and Kaliski-Ford Described on Web Site
Date: Sat, 16 Jun 2001 19:06:01 GMT
Yes, I finally got around to it, after discussing such matters quite
some time ago in a few posts on this newsgroup.
The location is:
http://home.ecn.ab.ca/~jsavard/mi060804.htm
formerly the site of a description of the interlock protocol, which
has now been moved to the end of the section.
I think my descriptions, though short and simplified, are correct and
accurate as far as they go. I have links to the original descriptions
of SRP and PAK-R; unfortunately, for the other two, I can't link
properly to the sites harboring the PDF documents, for which I only
have offsite links.
(I don't like providing a direct link to a download which really
belongs to someone else's site, and a link to a third-party page is
only confusing IMO.)
I also included my own wretchedly elaborate protocol, previously
described here - with one additional correction, of course. Also added
is a statement of what its design goals "really" were; although I
depend on the security server to be secure, and keep its secrets, I
don't *trust* it, and want the computational host, unable to keep
secrets, to resist _active_ external attacks. There's a
straightforwards way of doing that (*digital signatures*) but I did
things the complicated way (hey, it saves a public-key computation).
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Sat, 16 Jun 2001 19:26:58 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : "SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>
> :> 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.
>
> You can /sometimes/ get a secure system - even if your cypher has a break.
If a transform L is entirely linear [not just biased so] then there is no
method of turning it into a secure transform other than if the #key = #msg
[i.e an OTP]. If we are talking about fixed width transforms like a block
cipher, if L is linear it must have some matrix form. Thus L o L is a
linear matrix, L o L o L is , etc...
Therefore if your transform is linear there is no amount of extra rounds/etc
that can make it secure.
> For example, if there's an attack on Rijndael that takes N bytes of
> known-plaintext, then compressing the messages so that more of them are
> smaller than this is likely to decrease the proportion of them that can
> be read using this attack.
Or just increase the # of rounds which is what alot of cryptographers are
suggesting for long term security.
> I think /some/ paranoia in needed among cryptographers. If you believe
> your cypher is secure, that faith may be your undoing.
Yes, I have to agree here. Even the AES officials are lame. Rijndael
really should have a few extra rounds just to be extra cautious.
> Of course paranoia can be taken to unhealthy extremes - but one of those
> unhealthy extremes appears to be not having any at all.
Agreed.
Tom
------------------------------
Date: 16 Jun 2001 19:40:02 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
David Hopwood writes:
> 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/
Non-malleability essentially means that you can't alter a ciphertext and
get a plaintext with a predictable change. CBC fails because if you flip
a bit in a CBC block, it causes the corresponding plaintext bit in the
following block to flip. This is at the cost of turning the current block
into garbage. But still it is not good to allow this kind of change.
(In particular you can change an IV bit and make a predictable change
to the first block of plaintext without producing any garbage.)
CFB (when used with a shift size equal to the block size) has exactly the
same property, except that the plaintext bit flipped is in the current
block and the garbage is the following block. This allows you to make
undetectable changes to the last block.
CTR (counter) mode is even worse. Flipped bits in the ciphertext go
straight through to the plaintext without producing any garbage at all,
and likewise with OFB. With ECB mode you can interchange blocks without
producing garbage so it is bad too. And of course with any of these
modes you can truncate a message on block boundaries.
It appears that none of the classical chaining modes provide non-
malleability. In fact the HAC *defines* non-malleability as a property
of public key ciphers (definition 8.60). Nevertheless it is an important
property, as the recent Czech attack on PGP showed. That attack exploited
the ability to make small, predictable changes to the encrypted private
keys in order to induce various faults that could leak key values.
The usual way of achieving effective non-malleability is with another
layer of protection, either a signature or a MAC. I believe the
XML encryption standard does include the option of using a MAC,
although it is not required. As the paper you cite points out
(also the June 6 paper by Hugo Krawczyk from the eprint archives at
http://eprint.iacr.org/curr/), the MAC should be done after encryption.
This is perhaps somewhat counter-intuitive; instinctively one might think
it safest to hide everything within the encryption envelope, including
the MAC. But the emerging consensus definitely seems to be the opposite,
and a new standard like XML encryption should take advantage of the
latest cryptographic knowledge.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Date: Sat, 16 Jun 2001 19:52:40 GMT
"lcs Mixmaster Remailer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> CTR (counter) mode is even worse. Flipped bits in the ciphertext go
> straight through to the plaintext without producing any garbage at all,
> and likewise with OFB. With ECB mode you can interchange blocks without
> producing garbage so it is bad too. And of course with any of these
> modes you can truncate a message on block boundaries.
Why is this a fault of CTR? CTR is not a MAC or HASH mode of operation.
Tom
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Is ECB truly more secure than CBC?
Date: 16 Jun 2001 20:25:58 GMT
[EMAIL PROTECTED] (lcs Mixmaster Remailer) wrote in
<[EMAIL PROTECTED]>:
>David Hopwood writes:
>> 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/
>
>Non-malleability essentially means that you can't alter a ciphertext and
>get a plaintext with a predictable change. CBC fails because if you
>flip a bit in a CBC block, it causes the corresponding plaintext bit in
>the following block to flip. This is at the cost of turning the current
>block into garbage. But still it is not good to allow this kind of
>change. (In particular you can change an IV bit and make a predictable
>change to the first block of plaintext without producing any garbage.)
>
>CFB (when used with a shift size equal to the block size) has exactly
>the same property, except that the plaintext bit flipped is in the
>current block and the garbage is the following block. This allows you
>to make undetectable changes to the last block.
>
>CTR (counter) mode is even worse. Flipped bits in the ciphertext go
>straight through to the plaintext without producing any garbage at all,
>and likewise with OFB. With ECB mode you can interchange blocks without
>producing garbage so it is bad too. And of course with any of these
>modes you can truncate a message on block boundaries.
>
>It appears that none of the classical chaining modes provide non-
>malleability. In fact the HAC *defines* non-malleability as a property
>of public key ciphers (definition 8.60). Nevertheless it is an
>important property, as the recent Czech attack on PGP showed. That
>attack exploited the ability to make small, predictable changes to the
>encrypted private keys in order to induce various faults that could leak
>key values.
I think the reason that none of the blessed modes appear to have
good qualities for encryption is so that the NSA can break them
easier. I also fear idoits will start using CTR mode. Becasuse of
all the hype that it easier to use and secure. I don't think there
is much one can do. The trend will be to get people to use insecure
ciphers that seem safe on the surface but groups like the NSA need
people to use bad ciphers so they can read what is written, The
brain dead want to sound like they know something so they help
beat the drumns about the use of CTR mode. Again except for very
narrow applications it shouldn't be used at all. It was obvious
to people in the past it was weak, But I guess to dumbing down of
the current group of new crypto wantabes. They think its the greatest
thing since sliced bread.
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!
------------------------------
** 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
******************************
