<div dir="ltr"><div><span style="font-size:12.8000001907349px">Looks good. Some questions and comments:</span></div><div><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div>2. When RSA keys for the application are generated, a certificate for the user will also be generated which contains user data, fetched automatically from his system like user name, country etc. and certificate will be self signed with user's private key.</div></div></blockquote><div><br></div><div>Just a question to see if I understood this correctly: Is this private key you talk about something similar to the keys pairs that we currently exchange during the pairing? Are we also going to exchange these keys during the pairing with the new protocol?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>4. TcpServerSocket needs to be replaced with WebServerSocket, both are nearly same but WebServerSocket provides functionality to integrate TLSv1.2.<br></div></div></blockquote><div><br></div><div>What's the difference between QWebSocket and QSslSocket and why did you choose WebSocket in this case?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>1. Android by default uses Bouncy Castle(BC) library and JAVA library for various encryption purposes, BC will be further explored to generate certificates with the key.</div></div></blockquote><div><br></div><div>Just another question to see if I understand: The new kind of sockets will do all the encryption/decryption, and BC and QCA are now going to be used only to generate the needed keys and certificates? </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>4. This certificate will be used when applying TLS filter over session created by Apache Mina.<br></div></div></blockquote><div><br></div><div>Good call to use Mina so we get to reuse some stuff, and also shows you have documented about the current code works :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div>5. As pointed out by Albert, that KDE application upgrades are not as frequent as Android's, so a new LanLinkProvider (SslLanLinkProvider) will be used. So we will have two link providers in Android version of application.</div><div>6. Each link provider decide itself whether to create a link with other device based on its identity package which contains a field called isSslSupported.</div></div></blockquote><div><br></div><div>This does not scale very well when we add other protocol (eh: Bluetooth, direct USB connection, over the cloud...). I would try to simply instantiate always both protocols and one will fail to connect and the other will succeed, so we will use the one that succeded. If this doesn't work for some reason, maybe we can have an array like "supportedProtocols: ["ssl", "bluetooth"]", but anyway not a boolean per protocol.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>9. Since SslLanLink does encryption of data itself, so LanLink should also do it. So encryption of network package will be moved to LanLink from Network package so each link manages its own encryption scheme.</div></div></blockquote><div><br></div><div>Perfect, handling the encryption should be done inside the link, and not in higher level classes like Device as we do now. It would be nice to do this in the KDE side as well, even though we will only have one protocol for now.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>The use of TLSv1.2 follows Public Key Infrastructure(PKI), where there are some trusted parties and they verifies the certificate,i.e. these trusted third parties sign the certificate with their own private key. User can authenticate certificates by using the public key of third party. Since we cannot use third parties here and we assume that user trusts himself most, so during pairing process hash of public key will be shown to user to verify it manually to avoid any Man-in-the-Middele(MitM) attack. Once the pairing process is done, other party's certificate will be saved and we will use that certificate for any future communication. This method ensure no MitM attack in the future.</div></div></blockquote><div><br></div><div>Showing a hash doesn't seem very user friendly. Maybe we can reduce that to a short pin (like the 4-digit numbers in bluetooth pairing).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>15 June – 21 June : Testing the application by running it on various devices(using different images in emulator)</div></div></blockquote><div><br></div><div>And fixing bugs :) You probably don't need to test it on many virtual devices, I have three phones I can use to test and you probably have one, so that should be enough. This way you can save time to use fixing bugs, because assume there will be bugs, and that they will take longer than expected to fix.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>4 July – 10 July : Generating certificates for KDE version of KDE connect and saving it</div><div>along with the key in PEM format.</div></div></blockquote><div><br></div><div>One week seems a lot of time to do this. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div>25 July – 31 July : Integrating both Android and KDE version with each other. Handling any problems caused due to difference in APIs and their implementation.</div></div></blockquote><div><br></div><div>One week seems quite short for this. You probably want to compact the previous tasks a bit so you have more time for this part.</div><div><br></div><div>That's all!<br></div><div>Albert<br></div><div><br></div></div></div></div>