[Jeffzheng]

I want to send a pubic_key packet(OP code:0x85) to another client. In the last part of this packet is a "signature" part, usually 76 Bytes .
I know public key contains two parts :modulus & exponent. What's the regular of write these two parts into the "signature" part of packet ? Write the modulus firse or exponent first ? What's the postition of them ?


This is a defination of R_RSA_PUBLIC_KEY in my project, but it's 258 Bytes more than the 256 Bytes how many the "signature" part can hold.

#define MAX_RSA_MODULUS_BITS 1024
#define MAX_RSA_MODULUS_LEN ((MAX_RSA_MODULUS_BITS + 7) / 8)

typedef struct {
unsigned short int bits; /* length in bits of modulus */
unsigned char modulus[MAX_RSA_MODULUS_LEN]; /* modulus */
unsigned char exponent[MAX_RSA_MODULUS_LEN]; /* public exponent */
} R_RSA_PUBLIC_KEY;

[fox88]

Why don't you take a look at eMule's sources and cryptographic libraries it uses? I believe it might be a bit faster way than expecting someone doing it for you.

[Jeffzheng]

fox88, on 24 March 2011 - 03:55 PM, said:

Why don't you take a look at eMule's sources and cryptographic libraries it uses? I believe it might be a bit faster way than expecting someone doing it for you.

Yes, I came here just because I can't found answers from eMule's sources . Thanks your reply anyway.

[Alexer]

fox88, that attitude isn't going to help bringing more developers to ed2k. If you want ed2k to die, then do as you wish, however, if you have any wish whatsoever to see ed2k used in the future, I suggest you try to help other developers instead of telling them to look at the source. Because, frankly, the source is something awful. Or, perhaps more probably, you're just saying that because you don't even understand the source yourself - and I'm not blaming you.

Jeffzheng, the packet format for all three secureident packets that I know of:

The SECIDENTSTATE (0x87) packet has one-byte "state" (haven't looked at what that does yet) and a four-byte "challenge".

The PUBLICKEY (0x85) packet has one-byte "length" and length bytes of public key data.
You can find a reference to the public key data format at the CryptoPP wiki. The public key data is in ASN1 format, which contains an algorithm identifier and the real key as embedded "binary" ASN1 data. The decoded key data then contains the modulus, n, and the public exponent, e, in that order.

The SIGNATURE (0x86) packet has one-byte "length" and length bytes of signature data.
The signature scheme used is RSASSA-PKCS1-v1_5 with SHA hashing (CryptoPP wiki page), which means that the data to be signed is first hashed using SHA, then padded using EMSA-PKCS1-v1_5 and finally signed (encrypted) with the signers private key. To verify the signature, you must first decrypt the signature data using the signers public key, which leaves you with EMSA-PKCS1-v1_5 padded SHA hash. Then you must either extract the hash and compare to the expected hash, or use EMSA-PKCS1-v1_5 padding to the expected hash and compare the padded hashes. Lastly, the data used for the signature is the other clients public key concatenated with the challenge the other user sent.

If you're planning on using an existing rsa keypair generated by emule or a compatible client, it is located in cryptkey.dat, and the format is described in the first CryptoPP wiki link (it is base64-encoded however). The data is again in ASN1 format, which contains an algorithm identifier and the real key as embedded "binary" ASN1 data. The decoded key data then contains a version identifier, the modulus, n, the public exponent, e, the private exponent, d, the first prime, p, the second prime, q, the first exponent, dp, the second exponent, dq, and the coefficient, qi, in that order. You really just need n and d for signing.

Also, as far as I can see, the "secident" protocol implemented by eMule offers NO PROTECTION WHATSOEVER against credit stealers. (except maybe security through obscurity, but really, it doesn't take that much to figure out..)
If someone thinks otherwise, I'm available for CREATIVE discussion. I'm by no means an expert in cryptography, so I may well be wrong, but I'm pretty damn sure I'm not
Also, apparently I'm not the only one that has noticed this, considering that there is a secident v2 (although it is not used by default), which actually gives some protection as far as I can see.

The description is long, but I hope it's clear enough to understand.

[fox88]

Alexer, on 29 March 2011 - 09:08 PM, said:

that attitude isn't going to help bringing more developers to ed2k

What attitude? It was pure luck that you happened to be passing by and decided to register and give an answer. Otherwise waiting time could be very long - that's what I usually see here. Docs are few and scarce, developers and modders are busy with their own things. Hence my advice: do not waste time waiting. If someone is interested: no, I did not study these parts of code.
Now for 'more developers' part.
A developer who cannot find in eMule's code where and how specific type of packet is prepared? You must be joking.
If you read carefully, there is a chance to notice that OP is trying to send eMule's packet from other application. Where you see another developer, there is (most probably) just another scholar's study of cryptography in networks.

Alexer, on 29 March 2011 - 09:08 PM, said:

Because, frankly, the source is something awful.

Could you show your own project with ~20MB of sources, still crystal clear and not awful in many ways?

This post has been edited by fox88: 04 April 2011 - 12:38 PM