faissaloo
Key generation
Hi faissaloo, just wanted to compliment you on this project, looks awesome and got me kind of interested in crypto :)
In the Readme you propose to outsource some of the calculation work to a server. I tried that and it works. Decomposing the primes can be done with the linux standard tool factor, it's fast and mature and no harm done when sending the data unencrypted.
However, the bigger problem is this line, it takes more time than prime decomposing and it cannot be outsourced to a server because this is private key stuff. That's why I think the server approach will not work to get the auth handshake to a reasonable amount of time.
One solution might be to restrict the app to JSR177-capable devices, where those things can be calculated natively in the JRE. However, I'm not expert enough to wrap my head around it, also I fear I'd make mistakes that would sabotage the whole encryption.
I don't think Java 2 ME's JSR-177 has the latest crypto technology to work with Telegram, but that's worth to investigate I'll check if my phone has that specification
@baumschubser Hello, sorry for replying so late I got bogged down with life stuff. Thanks for your kind words.
I wasn't aware of factor, based on what you've said it seems that all we really need is a simple TCP server layer ontop of that. You're correct that the RSA takes way more time than prime decomposing, I just neglected to mention it since I didn't think that was avoidable.
Using JSR177 is a great idea, I wasn't previously aware that such a thing even existed. There's no need for us to restrict ourselves only to devices that support it since we can use Class.forName to check if the relevant functionality exists and provide fallbacks if not.
I fear I'd make mistakes that would sabotage the whole encryption.
The priority is to get something that actually works first. Security is important but it's secondary and it would be my responsibility to check your code before it goes in anyway.
@JoseskVolpe
I don't think Java 2 ME's JSR-177 has the latest crypto technology to work with Telegram
It's sorely lacking yes, but there are a couple of things that it can do like SHA-1 digests and RSA which we could take advantage of and could potentially provide a very large speedup since they're part of the runtime, instead of doing them all at the Java layer which is extremely slow.
I tried to re-introduce myself to the crypto of getting a Telegram auth key and how to use the JSR177-provided methods in there. I must say, I don't know enough about it all to implement this.
But I just sent you a pull request for this:
I wasn't aware of factor, based on what you've said it seems that all we really need is a simple TCP server layer ontop of that.
PS: I am working on a little J2ME Telegram client that uses a custom "proxy" server that handles all heavy lifting and communication with Telegram itself. I figured this is easier than to optimize a pure J2ME app to make it work fast enough to be actually usable. It still is a lot of work, though :)
I am working on a little J2ME Telegram client that uses a custom "proxy" server that handles all heavy lifting and communication with Telegram itself
Do keep me posted regarding the client, I'm sure there'll be plenty of code we can exchange