Cryptography-Digest Digest #58, Volume #13 Tue, 31 Oct 00 15:13:00 EST
Contents:
Re: Rijndael Key Schedule (Tom St Denis)
Re: BEST BIJECTIVE RIJNDAEL YET? (SCOTT19U.ZIP_GUY)
Re: Is RSA provably secure under some conditions? ("John Feth")
Re: A new paper claiming P=NP (Darren New)
Re: Padding scheme? (Benjamin Goldberg)
Re: XOR based key exchange protocol - flawed? (Benjamin Goldberg)
Re: shared secret signing using a hash... (Simon Johnson)
Re: Is RSA provably secure under some conditions? (Simon Johnson)
BENNY AND THE MTB? (SCOTT19U.ZIP_GUY)
Re: Is RSA provably secure under some conditions? (DJohn37050)
Re: shared secret signing using a hash... (Tony L. Svanstrom)
Re: How do I detect invalid passwords? (David Hopwood)
Re: shared secret signing using a hash... (Tony L. Svanstrom)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Rijndael Key Schedule
Date: Tue, 31 Oct 2000 17:49:52 GMT
In article <8tmffc$23fo$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Trish Conway) wrote:
>
> In the Rijndael key schedule the first subkey is just a copy of the
userkey(for a 128 bit userkey). Could the following scenario be
interpreted as a weakness : Say the subkeys are generated in a black
box in hardware and an unauthorised person breaks into the black box
and obtains the subkeys. They now have the userkey and can go to
another black box and input the userkey and impersonate a legitimate
user(supposing that the userkey is distruted to a number of users all
using a central host).
Um... regardless if I capture the round keys I don't need to know the
original master key. Your attack is not valid.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: 31 Oct 2000 18:08:10 GMT
[EMAIL PROTECTED] (James Felling) wrote in
<[EMAIL PROTECTED]>:
>In any compression scheme the message length is encoded.( it may not be
>encoded as additional data however)
I like you deinfations the is encoded but may not be encoded as
addtional information.
>In your example the "compression routine" is length preserving. Therefor
>the length of the original plaintext is exactly the length of the
>output. That routine "embeds" length information in its output -- the
>length out =length in.
>
>OTOH if my compression routine changes the length of the data it must
>encode that information in some way within the file, either by a "stop"
>character, or a "termination state" for the algorithim, or some form of
>embeded length field.( this may be as simple as if you hit EOF then
>stop)
I guess by no information I am using the EOF of the operating
system to say file has ended. But this is entirely different than
using a "stop"character since the file that contains a stop characater
may have it in a place other the true end of the file. So its a waste
of space to desing a file terneination system using data internal to
the file.
>
>
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: "John Feth" <[EMAIL PROTECTED]>
Subject: Re: Is RSA provably secure under some conditions?
Date: 31 Oct 2000 18:07:49 GMT
John Malley,
I'm sure that Canetti, Goldreich, and Halevi (Random Oracle Methodology,
Revisited authors) are serious in their efforts and I'm glad to have the
paper to review. But I must admit, the proofs they offer for their
theorems, and even the definitions they give for use in their theorems are
opaque. I think the opacity is due to the notation they use and the lack
of an appendix that makes clear how the notation works.
It seems to me that including in the paper an actual example of a
cryptographic system that passed the random oracle test but failed to be
secure in implementation would go a long way to providing insight into the
perils of implementation. Otherwise, I'm left feeling that I'm reading an
abstraction about an abstraction.
Sure, my ignorance is profound, but a little clarity of notation will help
lift the veil. Is their some Notation Oracle hiding out there?
John Feth
John A. Malley <[EMAIL PROTECTED]> wrote in article
<[EMAIL PROTECTED]>...
>
> Yes, some notions of "provable security" are subject to change. Check
> out "The Random Oracle Methodology, Revisited" by Ran Canetti, Oded
> Goldreich and Shai Halevi, dated October 11, 2000 at the LANL on-line
> archive but originally appeared in the Proceedings of 30th Annual ACM
> Symposium on the Theory of Computing, pages 209-218, May 1998, ACM:
>
> http://xxx.lanl.gov/abs/cs.CR/0010019
>
> They show a most marvelous thing: There exist signature and encryption
> schemes that are secure in the Random Oracle Model but for which any
> _implementation_ of the random oracle results in insecure schemes. The
> fact that a scheme is secure in the Random Oracle Model cannot be taken
> as evidence or indication to the security of possible implementations of
> this scheme. Evaluating schemes with the Random Oracle Model rules out
> some, but not all, insecure schemes.
>
> Made my jaw drop.
>
> Gosh, the math in the paper itself made my jaw drop. Still reading it,
> do not yet completely understand their proofs but I'm working on it.
>
> John A. Malley
> [EMAIL PROTECTED]
>
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: comp.theory,sci.math,sci.op-research
Subject: Re: A new paper claiming P=NP
Date: Tue, 31 Oct 2000 18:20:13 GMT
Timothy Chow wrote:
> That's bad.
Try "postmaster@..."
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
The tragedy of the commons applies to monitizing eyeballs, too.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Padding scheme?
Date: Tue, 31 Oct 2000 18:57:47 GMT
Tim Tyler wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> : SCOTT19U.ZIP_GUY wrote:
> :> [EMAIL PROTECTED] (Benjamin Goldberg) wrote in
> :> <[EMAIL PROTECTED]>:
>
> :> >After having read some other recent stuff on this group discussing
> :> >padding, I realize that a trojan horse type program could use the
> :> >random padding as a subliminal channel. To avoid this, the
> :> >padding should, instead of being random, be the first bytes and
> :> >bits from a cryptographicly secure hash of the message. [...]
> :>
> :> Yes this might be valuable if the padding is applied in some
> :> purely bijective way so that the result is still fully bijective.
> :> [...]
>
> : Although it's true that using bits from a hash, rather than bits
> : from a TRBG, does create a bijective mapping from the set of
> : messages whose lengths are multiples of 8 bits to the set of
> : messages whose lengths are multiples of 128 bits [...]
>
> s/true/false/
>
> You've just added a redundant section to the message. A bit like
> cutting the first few characters and pastuing them onto the end of the
> file. No bijective map is likely to be found there.
Note that the domain and range are not the same. The domain is the set
of messages whose lengths are integral numbers of 8-bit bytes. The
range is the set of messages whose lengths are integral numbers of
128-bit blocks. If the hash of the message is used as the source of
'random' padding bytes, then each message in the domain maps to
precisely one message in the range. Furthermore, the inverse function,
which strips padding, maps each message in the range of the padding
function to one and only one message in the domain. Does not this
padding scheme describe a mapping that is one-to-one and onto?
> : there is no significant difference in security between the original
> : 1-to-many mapping and the hash-based 1-to-1 mapping.
>
> You don't rate that ability to reject keys on the basis of their
> having appended padding in the form of hash data (that doesn't
> match the contents of the message) as a security risk?
Consider that the entire message must be decrypted to be able to reject
a key. There's a tradeoff... either use a RBG to create the padding,
and risk the possibility of a subliminal channel being snuck in (a
trojan horsed encryption program) by your opponent, or use hash bits,
which allow rejection of keys. I personally would use an RBG to create
the padding, but that's because, if I'm implementing it, I know that my
RBG is not trojan horsed.
> Don't expect folks like me or David to agree with that.
Well, like I said, you can either introduce a known (minor?) weakness,
which can't have a subliminal channel, or risk the unknown weakness of
your enemy (possibly) introducing a data leak.
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: XOR based key exchange protocol - flawed?
Date: Tue, 31 Oct 2000 18:57:50 GMT
David Wagner wrote:
>
> Mike Connell wrote:
> >Pa, Pb are RSA public keys. (X)Pi means data X encrypted under key
> >Pi. Xa, Xb are random blocks of data of the same size as the public
> >keys.
> >
> >1. a -> b : Pa
> >2. a <- a : Pb
> >3. a -> b : (Xa)Pb
> >4. a <- b : (Xb)Pa
> >
> >Then a and b compute the XOR of Pa,Pb,Xa,Xb.
>
> I don't understand the "MITM attacks" others are posting on your
> scheme.
>
> If you don't have any way to validate the public key that the other
> guy is using, then any authentication protocol you use will be
> susceptible to a MITM attack. That's just unavoidable, and is not
> a flaw of the authentication protocol.
>
> The point is that secure authentication protocols tell you, at the
> end of the protocol run, who you are talking to. An attack is where
> the malicious guy Mallet can get you to think you are talking to Alice
> when in fact you are really talking to Mallet.
>
> It is NOT an attack if at the end of the protocol you think you are
> talking to Mallet and you are correct in this belief. If you send
> secrets to Mallet, knowing that it is her that you're sending them to,
> well, that's not the fault of the authentication protocol.
>
> In this case, when the protocol completes, I think you always know
> the public key of the other person you are talking with. There are
> other issues (like replay attacks), but I don't think MITM attacks
> is one of them.
>
> Am I missing something?
Yes. Since the public keys are transmited *as part of the protocol*,
this implies that they are ephemeral, and were generated for this
session only. You therefor can't know who they actually belong to. If
the protocol said that, at some earlier time, a and b had exchanged
public keys, and b trusts that the owner of "public key a" is a, and a
trusts that the owner of "public key b" is b, then what you said would
be absolutely 100% correct.
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: shared secret signing using a hash...
Date: Tue, 31 Oct 2000 19:14:02 GMT
In article <[EMAIL PROTECTED]>,
Anders Thulin <[EMAIL PROTECTED]> wrote:
> "Tony L. Svanstrom" wrote:
>
> > $data = 'this is the string';
> > $signature = md5_base64 "[this is the secret] $data";
>
> For more on that particular topic, try RFC1828 and RFC2104.
>
> --
> Anders Thulin [EMAIL PROTECTED] 040-10 50 63
> Telia Prosoft AB, Box 85, S-201 20 Malm�, Sweden
>
There are Perfectly secure Secret sharing schemes. Why use anything
less?
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Is RSA provably secure under some conditions?
Date: Tue, 31 Oct 2000 19:10:59 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jan Fedak) wrote:
>
> Hello.
>
> I wonder are there any conditions under which RSA is provably secure?
> I've seen a small note saying something like RSA is provably secure if
> public exponent is 2 or 3 but I'm not sure about it and I can't find
the
> reference any more.
>
> Moreover, I've found some articles claiming that breaking RSA with low
> public exponent is easier.
>
> Thanks, Jan
>
> --
> Jan Fedak talk:[EMAIL PROTECTED]
> mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
> Linux - the ultimate NT Service Pack.
>
RSA is not proveably secure in any situtation because we are not sure
that:
1. The solution to RSA depends on knowing the factors of the
Modulo.
2. that P!=NP.
Using public exponents of 2 and 3 is insecure in some circumstances.
The Chinnese remainder theorm can solve RSA if the different keys are
used to encrypt the same number as the size of the (common) public
expodent. In you're case, if the same document was encrypted twice or
three times with independent keys (but they share the same public exp)
then the solution can be found.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: BENNY AND THE MTB?
Date: 31 Oct 2000 19:17:30 GMT
What follows is a story that may or may not be true
Supose there is a group that is sending messages and they
have a code book of 256 symbols most of which are words.
The MTB ( a fictitous group) has been monitoring them
and wants to know what the leader Benny lewis ( also fictistous)
is sending to them. The group started by sending messages by
hand but the MTB got a copy of the code book. After a period
of time Benny and his boys decide to get modern so they stated
using QHQ in the non public key mode. The mode where the public
is using compression and encryption. But the boys back at the MTB
laugh since even when they have been out drinking they brag they
can decrypt any QHQ program with there methods. The boys know
that there billion dollar quantam computer can find the solution
of almost all meassages since usually there is only one possible
solution to the decryption compression process and there tool
swiftly locks in on it. But Benny is no fool so he still keeps
the code book for first layer and then decides to use Matt's
bicom program to do the compression and encryption. The resultant
file is then zipped and sent to the internet.
THe boys still laugh since they have heard that Riandoll is the
encryption method that Matt used. And they already have a patch
to handle the expected inclusion of the cipher to QHQ. So they
spend a week to modify it to use Matt's bijective compression.
They are still laughing when they get the first message to
decyrpt. Since it is only a byte long. Some of the boys don't
even want to try to turn the quantum computer on. One byte they
say. How many possible messages could that decrypt to. But for
grins they test it out. It spits out a 20 byte answer that they
run though the code book. The message does not quite make sense so
they do it again. They get a 16 byte message this time.
They think something is wrong with the machine. Then a tech
with a high school degree reminds them that it spits out at
random a possilbe valid anwser. So maybe there is more than
one possible answer. Something that has not happend with all
the QHQ messages they worked with before. So they decide to
really take a long time they run the thing all nite. Spitting out
thousands of possilbe messages that could have been encrypted
into that one byte. By this time they are worried they realize
there billion dollar quantum computer is worthless and that there
are at least 2**100 different possible messages that could have
been sent. They are at a loss. THey do the only thing they can
they try to convince the public that bijective compression
with bijective encryption is bad. They make sure QHQ never makes
use of this scheme. But Benny does not stop using it. He later
add other bijective compression encryption schemes in series. He's
no fool he stays one step ahead.
What follows is the one byte file that came from the zip file:
xdump r.bia
0000 78 . . . . . . . . . . . . . . . *x*
number of bytes is 1
What follows is Bennies message in the secret code format
note it is 17 bytes ( code words) long.
bicom -d -p no_shit_password r.bia r.raw
0000 29 B5 1D 02 B5 1D 52 68 79 76 85 29 B5 68 30 6D *).....Rhyv.).h0m*
0010 D5 79 AF . . . . . . . . . . . . . *.y.*
number of bytes is 19
Also note that any password you try to decrypt compress with get
a totally different file. I bet you can't even find two passwords
that decrypt decompress to the same file.
THe boys at MTB are scared they thought by allowing Riamdoll
any implementation in a QHQ type of format would be easy to break
by there quatum computer.
**the above story false but the fact concerning matts bicom and
and the file and password using facts are not. They are true.
Cherrios
Try this with any other compression encryption program you can't
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: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Is RSA provably secure under some conditions?
Date: 31 Oct 2000 19:53:48 GMT
Yes, it is at least concievable that low exponent RSA is insecure but high
exponent RSA is secure. You can show that low exponent RSA leaks a lot of
info, so in some sense is the worst case, if RSA is able to be broken.
Don Johnson
------------------------------
Subject: Re: shared secret signing using a hash...
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Tue, 31 Oct 2000 19:57:46 GMT
Simon Johnson <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Anders Thulin <[EMAIL PROTECTED]> wrote:
> > "Tony L. Svanstrom" wrote:
> >
> > > $data = 'this is the string';
> > > $signature = md5_base64 "[this is the secret] $data";
> >
> > For more on that particular topic, try RFC1828 and RFC2104.
> There are Perfectly secure Secret sharing schemes. Why use anything
> less?
Lots of reasons, but this time I asked about hash-related things because
I'm interested in what ways people are using these algorithms besides
the plan ol' verifying of files/texts.
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
on the verge of frenzy - i think my mask of sanity is about to slip
---���---���-----------------------------------------------���---���---
\O/ \O/ �99-00 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
Date: Tue, 31 Oct 2000 20:03:39 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: How do I detect invalid passwords?
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> David Hopwood wrote:
> > [re: using a hash of the password as a key after authenticating
> > using a strong password protocol]
> >
> > No, that would defeat the point of using a strong password protocol,
>
> I was only proposing the use of the strong password protocol to prove
> knowledge of the hash, for that purpose it is quite suitable. However
> it is a valid point, and I'm sure there's some way around it, I'm just
> not sure immediately what it is.
?? I described a way around it in my post.
> > because the hash can be verified off-line. Generally all of these
> > protocols will produce a shared secret, as well as authenticating the
> > user. Use that shared secret to derive keys for encrypting, decrypting
> > and/or authenticating any data that needs to be sent.
>
> The immediate problem is that the shared secret is effectively one-time
> (otherwise there are other attacks that can be mounted on the systems
> involved).
Yes, of course it is (more precisely it is per-session). Why is that a
problem?
If you also need a permanent key, it can be stored by the server (possibly
encrypted under a salted hash of the password). If the client cannot
store any permanent data, then it would be sent on each session after an
encrypted, authenticated session has been established. This is quite
different from sending a key derived directly from the password in the
clear.
Note that authenticating the user only when a session starts (i.e.
without at least ensuring the integrity of the data sent using a MAC) is
fairly useless by itself, because it doesn't prevent a legitimate session
from being hijacked by an attacker. That's the main reason why these
protocols also produce a per-session shared secret, that can be used to
derive cipher and MAC keys.
- --
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
iQEVAwUBOf5SFjkCAxeYt5gVAQG2RggAp0lVz4ZGt6Rkl0+dcZaOoDG8mwNTSvsE
q1A/eb4TcW3NDU7vj+TOFaB9qpEgiixqk7s0iIUPlui3/d/ACQTgP7K4mTJIDwEs
bQak40mOeLHIRjQM+TuyqnDpbPy6MDY3gKu6GV5KQhdR8xXV9u0FGoIaAwHhIXZr
doSpkqZzPSz5iEO1gB1wABGWKJzFywNLqsQ/bnf0RgWzVce7nuIUjjvE+tmBsHNZ
Wdjy6xKlnq2ujRGoiyCDoRL1y5JpBkpsdLOykTcLuDa+uNMJUeUiAUDt1S5I4akO
f64671SZu8XFMaamD77oR2QPB+w7vAvwQFUNS2nVA99WivGTK0sZ/g==
=EseI
=====END PGP SIGNATURE=====
------------------------------
Subject: Re: shared secret signing using a hash...
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Tue, 31 Oct 2000 20:08:31 GMT
Simon Johnson <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Anders Thulin <[EMAIL PROTECTED]> wrote:
> > "Tony L. Svanstrom" wrote:
> >
> > > $data = 'this is the string';
> > > $signature = md5_base64 "[this is the secret] $data";
> >
> > For more on that particular topic, try RFC1828 and RFC2104.
> There are Perfectly secure Secret sharing schemes. Why use anything
> less?
Lots of reasons, but this time I asked about hash-related things because
I'm interested in what ways people are using these algorithms besides
the plan ol' verifying of files/texts.
Besides, you'd still need to share the secret somehow... :-)
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
on the verge of frenzy - i think my mask of sanity is about to slip
---���---���-----------------------------------------------���---���---
\O/ \O/ �99-00 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
** 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
******************************
