By having a look into the code and in wireshark, we discovered that your crypto might be broken. The standard is PKCS1 1.5 might be suspectable to padding oracle attacks, better use PKCS1 OAEP. But it is not the best idea to build your own crypto, better use TLSv1.2 also implemtend by qca. Then you have a symmetric data encrytion and for authorization (key exchange) asymmetric encryption. Also your code is not save against replay attacks. Especially it is dangerous for the mouse and remote control functions. Reproducible: Always
Hello Hinrikus, and thank you for spending some time testing kdeconnect's security. I'm aware that implementing our own encrypted protocol was a bad idea and that it is weak. Actually, I'm waiting to tag a "1.0" release until we manage to solve our security problems. I didn't realize that kdeconnect is also susceptible to replay attacks, so thank you again for pointing it out. The problem is that nobody working in KDE Connect has enough background in security to build a rock-solid encryption... Would you like to help us with that? :D Cheers, Albert
The article "KDE and Google Summer of Code 2015 Wrapup" [1] states: > This year Vineet Garg improved the secure communication over the network and added the support for TLSv1.2 to KDE Connect. Does that mean that this bug is resolved fixed? Is it safe to kdeconnect my phone to my computer via the internets using the "Add device by IP" option? [1] https://dot.kde.org/kde-and-google-summer-code-2015-wrapup
It's not merged yet, but we made some progress recently so it soon will be.
Version 1.0 to be released in the next weeks will use SSL sockets.