Cryptography-Digest Digest #82, Volume #13 Fri, 3 Nov 00 10:13:01 EST
Contents:
Re: Give it up? (Tom St Denis)
Re: Q: Computations in a Galois Field (Tom St Denis)
Re: Detectable pattern in encoded stegaanographic images (Andre van Straaten)
Re: Crypto Export Restrictions (Jeffrey Williams)
Re: Is RSA provably secure under some conditions? (Bodo Moeller)
Re: Detectable pattern in encoded stegaanographic images (SCOTT19U.ZIP_GUY)
Re: Q: Computations in a Galois Field (Mok-Kong Shen)
Re: Give it up? (Mok-Kong Shen)
Re: srp-1.7.0 released w/TLS Telnet security, X11 forwarding support (Paul Rubin)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Date: Fri, 03 Nov 2000 12:50:11 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Tom St Denis wrote:
> >
> >
> > > But known-plaintext attack (the zero bytes mean that
> > > part of the plaintext is known) is one of the commonly
> > > considered attacks, isn't it? Note also that my contrived
> > > example was meant only to give some intuitive feeling to
> > > conceive why a compressed sequence with reduced redundancy
> > > is better for crypto processing.
> >
> > Yes, but known-plaintexts attacks normally require much more then a
> > single block. Just because you have 1,000,000 known plaintext
blocks
> > in something like Rijndael doesn't mean you are one step closer to
> > learning the key or the message (again assuming the message blocks
are
> > not part of the known space).
>
> Another poster has already answered to this point. Do
> you agree that this known information does render the
> chance of analysis a bit higher, even if in practical
> cases that chance may still not be sufficient to effect
> a break? Note that DES has been broken by brute force,
> not by sophisticated, theoretically interesting,
> techniques in practice, as far as I know.
Technically... well sure it would "help" but practically is a different
story. With only 2^20 blocks from an AES cipher you do not have enough
information to mount any form of attack (or on the full cipher anyways)
which means brute force is still the only way to go. Sure you now have
a method to test your key, but that doesn't matter.
> >
> > > This is in my view not the right type of argument against
> > > 1-1. If you have an extremely secure block cipher, then
> > > by definition you don't have to care about anything else
> > > in the processing, whether you use compression or not. But
> > > that's not the point. The proponents of 1-1 claim (if I
> > > understand correctly) that, if you use compression followed
> > > by a cipher that is susceptible to brute force, then 1-1
> > > helps.
> >
> > But if it is a finite algorithm it is breakable in a finite number
of
> > steps. So I can *ALWAYS* brute force a 1-1 or non-1-1 system with
> > virtually the same ease.
>
> Whether the word 'same' exactly applies I am not quite sure.
> (But see also my words at the end of this post.) As to your
> first sentence, yes, anything other than the ideal OTP can
> be broken by brute force in principle, I believe, including
> a PK with one million digits.
This is not true. An OTP could theoretically be broken if the original
language is something like english and you have a jist of the
contents. Your success is next to nothing, but it is possible to guess
the right key (and never know it). RSA with a 10k-bit key can be
broken in finite time (just tons of it) as well. A symmetric cipher
with a 256-bit key can be broken in finite time as well (loads of
time...).
None of your arguments change the fact that a finite machine cannot
produce an infinite number of solutions. One of them has to be right...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Fri, 03 Nov 2000 12:52:17 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> Dumb question: For GF(2^m) with m sufficiently large, are
> there specific tricks in programming that could speed up
> multiplication/division? Thanks.
I believe you meant GF(2)^m as in a polynomial basis with binary
components. I keep getting mixed up with this as well (although people
have explained it...)
Um there are tons of tricks. Check out
http://security.ece.orst.edu/koc/Publications.html
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Andre van Straaten <[EMAIL PROTECTED]>
Subject: Re: Detectable pattern in encoded stegaanographic images
Date: Fri, 03 Nov 2000 13:00:49 GMT
[EMAIL PROTECTED] wrote:
> have tried to set up a method of steganographic transmission of images
> without suspicious attachments, by placing the file to be
> steganographically hidden, within the .bmp of the e-mail stationery .
> have used outlook express 5.5, used a .bmp of parchment texture [24
> bit] to use as the background stationery, used s-tools 4 to hide a pgp
> encrypted message within the background stationery, sent the e-mail
> with an innocent cover text, was able to retrieve the .bmp by right-
> clicking on the background and saving as a .bmp, and then retrieved the
> message using s-tools 4, without any problems.
> upon closer examination and comparison of e-mails with the plain
> parchment bmp background, and the same background with a textfile
> steganographically hidden within the background, found a very clear
> pattern in the base 64 encoding {when viewing the 'message source' and
> the encoding of the .bmp }, but no obvious patterns in the encoding of
> the plain .bmp
> is this just something in s-tools 4, or is it a consequence of the
> steganographic method showing a pattern between altered pixels and non-
> altered pixels.
> would be happy to send two sample e-mails for comparison to whoever
> would be interested.
Yes, please send the two files to:
[EMAIL PROTECTED]
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
______________________________________________
flames please to [EMAIL PROTECTED]
------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc,alt.freespeech
Subject: Re: Crypto Export Restrictions
Date: Fri, 03 Nov 2000 07:29:19 -0600
Comments are in line for clarity.
Anthony Stephen Szopa wrote:
>
> "IIRC people could not gleen exactly how the algorithm worked by
> reading those files,..."
>
> How do you know?
>
> What does "gleen" mean? Is that a new toothpaste?
Glean ("gleen" was a misspelling) means to gather information or material
bit by bit (Meriam-Webster).
>
>
> If you don't get it from reading the Help files you need to learn
> how to read. Many many people have read the Help files and ran
> the software and are using the software and they understand it all
> perfectly well.
The ability to use software effectively does not imply that the user
understands the underlying algorithms of the software.
------------------------------
From: [EMAIL PROTECTED] (Bodo Moeller)
Subject: Re: Is RSA provably secure under some conditions?
Date: 3 Nov 2000 13:39:23 GMT
Roger Schlafly <[EMAIL PROTECTED]>:
[...]
> Likewise, if I assume that SHA-1 is collision-free, then someone
> could look for collisions in order to test the validity of my
> assumptions.
>
> But if I assume that SHA-1 is a random oracle, then is no way for
> anyone to tell whether or not that is a reasonable assumption.
> Because in a literal sense, SHA-1 is not a random oracle, and
> it doesn't even make much sense to talk about how close it is to
> becoming a random oracle.
Maybe collision-freeness is a bad example here because for
one-parameter hash functions such as SHA-1 you cannot express it
formally in a way that really makes sense: After all, there *is* an
efficient algorithms that determines a SHA-1 collision -- basically
just two "print" statements. It's just that no-one knows their
parameters.
--
Bodo M�ller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Detectable pattern in encoded stegaanographic images
Date: 3 Nov 2000 13:51:39 GMT
[EMAIL PROTECTED] wrote in <8tsqgv$uv1$[EMAIL PROTECTED]>:
>have tried to set up a method of steganographic transmission of images
>without suspicious attachments, by placing the file to be
>steganographically hidden, within the .bmp of the e-mail stationery .
>
>have used outlook express 5.5, used a .bmp of parchment texture [24
>bit] to use as the background stationery, used s-tools 4 to hide a pgp
>encrypted message within the background stationery, sent the e-mail
>with an innocent cover text, was able to retrieve the .bmp by right-
>clicking on the background and saving as a .bmp, and then retrieved the
>message using s-tools 4, without any problems.
>
>upon closer examination and comparison of e-mails with the plain
>parchment bmp background, and the same background with a textfile
>steganographically hidden within the background, found a very clear
>pattern in the base 64 encoding {when viewing the 'message source' and
>the encoding of the .bmp }, but no obvious patterns in the encoding of
>the plain .bmp
>
>is this just something in s-tools 4, or is it a consequence of the
>steganographic method showing a pattern between altered pixels and non-
>altered pixels.
>
THe problem with most steganographic methods is that they really
try to hide the data by placing it in a place where no one looks.
The bad part is. As yourself have noticed is that when you do look
there is obvious diffeerences. Also like encryption the bad guys
have acces to steganographic tools. And if they apply them to the
graphic messages they could directly obtain the PGP messages. The
bad part is that it would be very hard to defend in court the fact
you where not sending PGP messages if PGP messags fall out. However
if you used something like BICOM to encrypt. YOu get a file with
not visable structure and it could be added to your graphics in
such a way that even if the bad guys recover the file they could
not prove its anything other than a random file. So it would be
harder for the bad guys to prove in court you even used stego.
>would be happy to send two sample e-mails for comparison to whoever
>would be interested.
>
>thanks in advance,
>
>vedaal
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Fri, 03 Nov 2000 15:05:53 +0100
Tom St Denis wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > Dumb question: For GF(2^m) with m sufficiently large, are
> > there specific tricks in programming that could speed up
> > multiplication/division? Thanks.
>
> I believe you meant GF(2)^m as in a polynomial basis with binary
> components. I keep getting mixed up with this as well (although people
> have explained it...)
No. I mean exactly GF(2^m), the finite field of order 2^m
(a Galois field that is known to exist). I don't know
the mathematical object you referred to or its relationship
to GF(2^m).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Date: Fri, 03 Nov 2000 15:05:31 +0100
Tom St Denis wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
{snip]
> > Another poster has already answered to this point. Do
> > you agree that this known information does render the
> > chance of analysis a bit higher, even if in practical
> > cases that chance may still not be sufficient to effect
> > a break? Note that DES has been broken by brute force,
> > not by sophisticated, theoretically interesting,
> > techniques in practice, as far as I know.
>
> Technically... well sure it would "help" but practically is a different
> story. With only 2^20 blocks from an AES cipher you do not have enough
> information to mount any form of attack (or on the full cipher anyways)
> which means brute force is still the only way to go. Sure you now have
> a method to test your key, but that doesn't matter.
Remember we were discussing in the general context of
whether compression CAN aid encryption. We were not assuming
that one has a sufficiently strong encryption algorithm
such that any 'aid' is superfluous from the very beginning
and consequently the goal of discussion becomes vacuous.
So if compression does helps to reduce the chance of
the opponent in some attacks, that could be interesting,
isn't it? We are discussing in this regard so to say
'theoretically' and not considering practical cases. In
fact, strong adherents of AES would consider having that
algorithm solves all security problems till eternity and
would totally ignore anything else, whether compression
or not.
> > >
> > > But if it is a finite algorithm it is breakable in a finite number
> of
> > > steps. So I can *ALWAYS* brute force a 1-1 or non-1-1 system with
> > > virtually the same ease.
> >
> > Whether the word 'same' exactly applies I am not quite sure.
> > (But see also my words at the end of this post.) As to your
> > first sentence, yes, anything other than the ideal OTP can
> > be broken by brute force in principle, I believe, including
> > a PK with one million digits.
>
> This is not true. An OTP could theoretically be broken if the original
> language is something like english and you have a jist of the
> contents. Your success is next to nothing, but it is possible to guess
> the right key (and never know it). RSA with a 10k-bit key can be
> broken in finite time (just tons of it) as well. A symmetric cipher
> with a 256-bit key can be broken in finite time as well (loads of
> time...).
>
> None of your arguments change the fact that a finite machine cannot
> produce an infinite number of solutions. One of them has to be right...
Your sentence regarding OTP shows in my view that you have
not properly understood the term 'perfect security' as
defined by Shannon. Your arguments in some previous posts
emphasize the practical security, claiming that opponent
can't do certain things if the work is too large, and now
you are arguing the theoretical security, claiming that
almost anything can be broken. Isn't there a fundamental
disparity? Anyway, I am done with this thread and I leave
others to examine whether what you wrote above is sensible
or that I am mistaken.
M. K. Shen
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Crossposted-To: comp.security.unix,comp.os.linux.security
Subject: Re: srp-1.7.0 released w/TLS Telnet security, X11 forwarding support
Date: 03 Nov 2000 06:21:00 -0800
I'm missing something--what's the point of using SRP in conjunction
with TLS? If you believe the TLS certificates, then TLS stops MITM
attacks so you can send the password in the encrypted TLS stream.
------------------------------
** 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
******************************
