Java and Python routers don't get along. :-(

Hez and thecrypto let's get together to standardize the specs crypto,
it's 2048 bit keys, 4096 are unnecessary at this time, although an
option to use such should be desirable at a later date.

Lance/0x90

-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Hezekiah
Sent: Monday, August 04, 2003 12:02 AM
To: [email protected]
Subject: [iip-dev] Java and Python routers don't get along. :-(

Hi, jrand0m and everyone! :)

On Sunday, August 03, 2003 15:04, auto97841-revL73yDgGBWk0Htik3J/[email protected] wrote:
> thanks hez, yes, definitely keep posting this stuff to the list.
pointing
> out bugs will hopefully shame me into doing more debugging ;)
>
> yes, the destination and a few other data structures were off-spec.
> They've been updated now.

	OK. I'll try again. :)

>
> One outstanding thing is the key size - thecrypto has implemented
4096bit
> ElGamal, while the spec says the public keys are only 2048bit.  (it
also
> says the private keys are 2048bit too, which isn't correct for asym).
>
> Does anyone have a good reason to use 4096bit instead of 2048bit for
> end to end encryption?  This is used only on the first message in a
series
> of dest<-->dest messages (later messages are AES'ed only, preceeded
with
> a unique random session tag).

	Well, I'm no crypto expert, but I'm not sure 4096 is really
necessary. There 
are mainly three things to consider (that I can think of.)

	1. A larger key is harder to break (bruteforce-wise that is)
	2. A larger key creates a larger encrypted message. This means
the _first_ 
message sent between Destination's will be even larger. Does this cause
a 
speed concern?
	3. A larger key takes longer to do its operations (at least in
my 
experience.) So decrypting with a 4096 bit key will take longer than
with a 
2049 bit key.

	Anyway, I'm not really a cryptographer, so I don't have a
qualified opinion 
on this, but I would say that I think 2048 is good enough for me.

>
> If not, I'm going to update the code and spec to reflect PublicKey
being
> a 2048bit Integer, PrivateKey being a 1024bit Integer,
SigningPublicKey
> being a 2048bit Integer, and SigningPrivateKey being a 2048bit
Integer.
>  Signature using DSA for a 2048/1024 public/private keypair is
currently
> set at 320bits.  Is this correct?  Also, SHA256 is set at 256bits.  Is
> this correct, or is it 256bytes?  AES messages are CFB with the IV
provided
> padded to 16byte blocks.

	OK. This sounds a bit wrong. :( Here's what I think it's
supposed to be:

	PublicKey	 (ElGamal public key): 2048 bits (256 bytes)
	PrivateKey (ElGamal private key): 2048 bits (256 bytes)
		(ElGamal public and private keys are about the same
size. It was the DSA 
public key that was 1024 bits.)
	SigningPublicKey (DSA public key): 1024 bits (128 bytes)
		(Note: this 1024 bits is as large as the DSS standard
permits. We had agreed 
that we were going to adhere to the standard.)
	SigningPrivateKey (DSA private key): 160 bits (20 bytes)
		(Yes. That's 160 bits. Read AppCrypt on DSA. The private
key is smaller than 
a 160 bit prime factor of (public key - 1). Hence, the private key is
only 
160 bits max.)
	DSA Signature: 320 bits (20 bytes)

	Also, SHA256 is 256 _bits_ (32 bytes), and AES was going to be
CBC. (During 
that confusing conversation about chaining, nop mentioned CFB, but when
we 
finally sorted it all out, he realized that the elements CFB provided
weren't 
needed. Thus, if I remember correctly, we had settled on using CBC
[since 
there was no reason to use CFB]). The IV is 16 bytes. (Might I note that
the 
16 byte IV is for use with a 256 bit (32 byte) AES key. So, you might
want to 
specify in the spec the size of the AES key. [I suggest a 256 bit (32
byte) 
length.])

>
> To be perfectly frank, I'm considering dropping the end to end
requirement
> and leaving that up to the application or even the api libraries to
> provide. However, specifying a common end to end strategy does allow
> security and enables inter-library applications to communicate.  The
other
> side of the coin is that if we didn't have end to end encryption (but
> merely verification), libraries would be able to work out their own
> interoperability standard.  [e.g. do kids calling their parents over
VOI2P
> to chat require the same encryption as a militant contacting other
> militants to plan an operation?]
>
> Thoughts?
>
	Hmmm. I think end-to-end encryption is very desirable as long as
you can 
still do what you want to with it. The main issue is speed. If you can
do 
streaming video with end-to-end encryption, then I see no reason why you

should remove it. I suggest this: Let's try it and see how it works.
Right 
now it will only be implemented in the client API. If during Alpha
testing we 
decide it's just too slow, we can come up with alternatives. Since it's
only 
in the client API, it will be easy to change. So I suggest we leave it
as is 
for now, and see how things develop. (Personally I think once you get
that 
big first message over with, it's a cakewalk from there on. I think what
we 
have right now can work.)

> -jrandom

	-- Hezekiah

P.S. jrand0m: In _theory_ the Python router should be able to handle all

non-admin messages with multiple clients. However, I haven't been able
to 
test it yet since I don't have a Python API to work with. Jeremiah and I
will 
be working on getting that up. Hopefully, I will have this basic local
router 
impl. with client API to you soon. (And hopefully, the Python version
will 
work with the Java version. If not, then we need to get our heads
together 
for a few hours sometime and solve the differences.)