please use this list :)

Hi, jrand0m & everyone else! :)

On Thursday, July 31, 2003 10:53, auto97841-revL73yDgGBWk0Htik3J/[email protected] wrote:
> Please do not send me private emails about the spec, the design, the
> code, or whatever (unless they're inherently personal in nature).  We
> want these discussions, including concerns and responses, to be out in
> the open on this mailing list, both to archive these decisions publicly
> and to give others the chance to see what is going into the reasoning
> behind various decisions.
>
> That is, unless iip-dev is supposed to be an announcements only list
> (in which case we'll need another)

	OK. Sorry about that. :)
	For those on the list, here's a little background. Last night at about 4 in 
the morning, I came across some things I thought might be problems in the 
network spec on Payload. I looked to see if jrand0m was online, so I could 
ask him my questions. He wasn't, so I started anonymailing him the questions. 
After getting annoyed to death by the 256 char message limit, I just email 
him the rest. Now that it's 2 in the afternoon and not 4 in the morning, I 
can clearly see that I should have sent those messages to iip-dev. I have a 
reflex of asking questions of developers via private mail due to all the work 
I've done with UserX. Anyway, sorry about all that folks. Here's what I 
talked to jrand0m about:


Hi, jrand0m! :)
	Well, I got sick of the 256 char limit on anonymail, so I'm emailing you all 
this. For the sake of it, I've included my previous anonymail messages, so 
you can have everything in one nice place. Here goes:

Anonymail #1: I just attract problems, don't I? :) Well, I thought of another 
one. In the spec for Payload you say that in Scenario 1 the first 32 bytes 
that were encrypted by the ElG key, are an AES key. I assume we'll be using 
this key in CBC mode. Where do we get the IV? I suggest it be found 
immediately after the key in the 256 byte block that was decrypted by the ElG 
key. Comments? :)

Anonymail #2: Here we go again. I was trying to implement Payload, when I hit 
a snag. The spec says that when a session tag is specified that the Payload 
body begins with a hash of the AES key. The problem is that with CBC the key 
is changing with each encrypt/decrypt. And in most libraries (like the one I 
have to use for Python) you can't just ask for the key. It's deep in the 
bowels of the library, and it won't come out. So that's 

	So that's where we are now. Now I continue:

	So that's the problem. It looks like all you were really trying to do was 
verify that the session id was used by someone who also had the AES key. So, 
here's what I suggest. Currently, a Payload starts with a session id and then 
has an encrypted body. Inside the body is the hashed AES key. I suggest you 
replace the hashed AES key with a copy of the session id. (This means there 
are now two places where the session id appears. Once at the begining of the 
Payload and once at the begining of AES encrypted body.)
	This still proves that Alice, who sent the message, has the AES key to go 
with the session id. If Alice were really an Malicious Mallory who had sent 
the session id, but used a fake AES key, it would become immediately 
apparent. When Bob decrypts the Payload body, he would see the session id 
doesn't match the one outside the payload body. That's the end of Mallory's 
attempt to fool Bob.

	The only problem I can think of with this sollution would be that it provides 
32 bytes on which you can try a chosen plaintext attack. However, I don't 
think that's a major concern.

	Anyway, it's 4 in the morning over here, so I could be _way_ off on the stuff 
I just said. What I _do_ know is that having to dig the key out of whatever 
crypto library is used, is _not_ something we should be doing unless we 
really need to. It would probably result in us having to either _seriously_ 
modify the crypto libraries we use, or have to write our own. (Neither of 
those prospects is entertaining to me.)

	So that's the current state of affairs. Tell me what you think. :)

	-- Hezekiah

P.S. And forgive me for causing your poor spec's so many problems. :)
P.P.S. I looked around in the Java code to see if you had a way of dealing 
with this, and discovered something minorly disturbing. It looks like you're 
implementing your crypto in Java. You're not _really_ going to use an 
implementation of AES written in Java, are you? Java might have its strong 
points as a language for rapid development, but speed is _not_ one of its 
strong points. How on earth would the crypto be fast enough to be effective 
if it has to be run through a Java interpretor!?


	Anyway, that's what I mailed jrand0m. Feedback anyone? Is this really a 
problem? Was a I just having delusions at 4 in the morning?

>
> Don't worry about flaming me or pointing out problems... my skin is pretty
> thick and I want this to turn out to be as secure as possible.
>
> Oh, one other thing.  Every time I hear a complaint saying "java is slow",
>  my respect for you goes down 10 notches, and if it happens enough, I'll
> /ig or killfile you.  This is not /. where fuzzy engineering is ok -
> speak not of which you do not know.
>

	OK. I've now learned that jrand0m and co. can encrypt 10KB of data at .6sec 
with their Java impl. of AES. I am properly humbled. :) (Personally, I can't 
wait to get to use this Java code if it's really that fast. This is rather 
exciting.)

	-- Hezekiah

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQA/KVyieHiZTMH32ioRAsY2AJ9mr/N/TXLdJNHKj/4j6Hklz+vfawCfa4F3
v9qGZXZpHy+0G/UTxNY4N7o=
=1e1H
-----END PGP SIGNATURE-----