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.)

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

iD8DBQA/LhMJeHiZTMH32ioRAm+/AJ0Qa5n0fk9x/pZdc3BqVjvCH6n/nQCdEXZY
kHAaXQxcYlaS3RsEYolhiK8=
=9mHJ
-----END PGP SIGNATURE-----