Hello again,>It doesn’t sound like you did profile, but rather a stop-watch at start and >stop. That’s more coarse-grained than I think you need to do. For example,>you need to measure time to do the key exchange, time to do the encryption, >time to put the traffic over the network. For example, try with aNULL and >eNULL and see what numbers you get. Then turn each on, separately, and see >what you get.I'm using a third-party library (Qt) that masks initial handshake message exchanges steps and data encryption. I could instrument Qt's internal methods to know how much time encryption takes versus data sending/receiving but that's pretty useless given that the client/server project I'm working on is not SSL-ed, my work consists in adding security. Therefore my profiling consisted in comparing times with encrypted and non-encrypted versions of the project, which gives me a rough estimation of encryption time. For handshake, I know that this phase is short because I know when it ends, I just didn't took the time to measure it precisely but I can easily come back with precise figures, I will have a look at it. >As a general design principle, the crypto algorithm is not the weak spot. >For>example, how hard is it to break into the client device?Well that's always >a compromise and this is what I'm curently trying to reach by reducing my >requirements in terms of key length for example. I partially agree with you in >that no system is proven to be 100% reliable but my work is not to care about >things I cannot handle like access to host device. On the other side, my work >is to use the most secure cipher suite I can afford relatively to performance >issue.
Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net
