4 ms·

1. I don't see how any of these threat models can't be addressed by doing server-side crypto. Server-side crypto libraries are more mature, more reviewed, and t

1. I don't see how any of these threat models can't be addressed by doing server-side crypto. Server-side crypto libraries are more mature, more reviewed, and thus by default better from a security standpoint. 2. The client side code is obfuscated. The server-side code is not provided. To perform a reasonable analysis of a system's security, a reviewer needs unobfuscated access to both. Why would you try and make security and crypto researchers de-obfuscate or guess your code, when that is not their specialization?

absherwin 13y ago
1. As discussed in another comment, this requires a similar level of trust to encrypting the data on the server. The only difference here is that, to the best of my knowledge, an attacker who took control of the server, could silently log the plaintexts in the server side case while some indication would be provided in the client-side case. Most wouldn't notice it but some would eventually. 2. The code I wrote isn't obfuscated. The code at the top is just SJCL and angular.js which are https://github.com/bitwiseshiftleft/sjcl https://github.com/bitwiseshiftleft/sjcl and https://github.com/angular/angular.js https://github.com/angular/angular.js
- AnIrishDuck 13y ago
  1. A server could silently insert code that replaces your keys with a well known one. Don't kid yourself into thinking anyone would notice this if it was silently tucked away in the minified angular or SJCL code. 2. Your definition of obfuscated and mine clearly differ. I'll be more direct: where's the (well-commented, clearly coded) model/controller code?
  - absherwin 13y ago
    1. Agreed. That's an avenue by which a vulnerability in the server or communication channel could be exploited. 2. It doesn't exist. The code was written in the same form it was uploaded.

4 ms·

1. I don't see how any of these threat models can't be addressed by doing server-side crypto. Server-side crypto libraries are more mature, more reviewed, and t

by AnIrishDuck 13y ago

absherwin 13y ago
1. As discussed in another comment, this requires a similar level of trust to encrypting the data on the server. The only difference here is that, to the best of my knowledge, an attacker who took control of the server, could silently log the plaintexts in the server side case while some indication would be provided in the client-side case. Most wouldn't notice it but some would eventually. 2. The code I wrote isn't obfuscated. The code at the top is just SJCL and angular.js which are https://github.com/bitwiseshiftleft/sjcl https://github.com/bitwiseshiftleft/sjcl and https://github.com/angular/angular.js https://github.com/angular/angular.js
- AnIrishDuck 13y ago
  1. A server could silently insert code that replaces your keys with a well known one. Don't kid yourself into thinking anyone would notice this if it was silently tucked away in the minified angular or SJCL code. 2. Your definition of obfuscated and mine clearly differ. I'll be more direct: where's the (well-commented, clearly coded) model/controller code?
  - absherwin 13y ago
    1. Agreed. That's an avenue by which a vulnerability in the server or communication channel could be exploited. 2. It doesn't exist. The code was written in the same form it was uploaded.