4 ms·

> Next time I won't post in a rush during work hours. I'd suggest taking the same approach with your "secure, end-to-end encrypted communications" app you keep

by nikcub 10y ago

> Next time I won't post in a rush during work hours. I'd suggest taking the same approach with your "secure, end-to-end encrypted communications" app you keep mentioning here[0] A one-way sha256 hash of a message using a password that has to be 8 characters long[1] and can't accept special characters[2] is not a secure communications app It is trivial to find the plaintext in these situations. Your Chrome extension has a very elementary RCI bug in it[3], which because of your extensions broad permissions[4] profile means anyone with your extension installed can have any code executed by visiting any page. To release (excuse me) crap like this on one hand while FUD'ing Google's security practices on HN on the other requires a level of hubris that I don't think i've ever previously encountered. [0] https://www.gibberit.com/ https://www.gibberit.com/ [1] http://i.imgur.com/CsgOkZ2.png http://i.imgur.com/CsgOkZ2.png [2] http://i.imgur.com/uZg0E4l.png http://i.imgur.com/uZg0E4l.png [3] http://i.imgur.com/eq19mET.png http://i.imgur.com/eq19mET.png [4] http://i.imgur.com/lOsibBP.png http://i.imgur.com/lOsibBP.png

libertymcateer 10y ago
Believe it or not, I very much appreciate your feedback.
- nikcub 10y ago
  I'd probably take the site down, or mark it clearly as being a hobby project. As for Chrome - that team has some of the smartest infosec and cryptography people in the world working on and contributing to the project. If you want some insight into how some of the security design principals and tradeoffs were rationalized, i'd start with the project wiki: https://www.chromium.org/Home/chromium-security https://www.chromium.org/Home/chromium-security
  - libertymcateer 10y ago
    It's currently marked as beta all over the site, for exactly these reasons.
    - nikcub 10y ago
      it is more prominently marked as "secure, end-to-end encrypted communications" - which it certainly is not. it is also being marketed as such by you here
      - libertymcateer 10y ago
        You can check again - I have changed the language. That was improper and thanks for the feedback.
nthm 10y ago
Could you explain how [3] is an RCI bug? getNum() returns either 'false' or 'n' with the length of gibberText (ie. n20, n35, etc). I can't imagine any content where .length() would return harmful code; though I'm not well versed in JS.
- libertymcateer 10y ago
  I'm also interested to know. Believe it or not, I would love to get Nik as a consultant. I fear my 'hubris' (I won't deny it, this idea is extraordinarily ambitious and I have to be arrogant to even conceive of it) will have pissed him off irrevocably. That aside, I don't really follow his point on the login PW. I understand 8 char alphanum pw is pretty low entropy... but that isn't used for encryption. And the login attempt rate is pretty strictly rate limited. And yes, I am getting professionals - not me - to do the heavy lifting. I wrote the proof of concept. I am in no way surprised to find it has issues - I am aware of a few others myself.
  - nikcub 10y ago
    It isn't the login password but the message password - although using sha256 for a login password isn't great either if you're doing aes(plaintext, sha2(password)) = cyphertext given cyphertext I can get to plaintext with sha2(8-char dictionary) well designed systems will generate a truly random key there, exchanged using public-key. if you're going to use a password, you need a key-derivation algorithm this is all bunk tho since the big vulnerability here is that you're delivering the encryption routines via javascript in a global browser space
    - libertymcateer 10y ago
      > this is all bunk tho since the big vulnerability here is that you're delivering the encryption routines via javascript in a global browser space So what about mailvelope?
      - libertymcateer 10y ago

by nikcub 10y ago

libertymcateer 10y ago

Believe it or not, I very much appreciate your feedback.

nikcub 10y ago
I'd probably take the site down, or mark it clearly as being a hobby project. As for Chrome - that team has some of the smartest infosec and cryptography people in the world working on and contributing to the project. If you want some insight into how some of the security design principals and tradeoffs were rationalized, i'd start with the project wiki: https://www.chromium.org/Home/chromium-security https://www.chromium.org/Home/chromium-security
- libertymcateer 10y ago
  It's currently marked as beta all over the site, for exactly these reasons.
  - nikcub 10y ago
    it is more prominently marked as "secure, end-to-end encrypted communications" - which it certainly is not. it is also being marketed as such by you here
    - libertymcateer 10y ago
      You can check again - I have changed the language. That was improper and thanks for the feedback.

nthm 10y ago

Could you explain how [3] is an RCI bug? getNum() returns either 'false' or 'n' with the length of gibberText (ie. n20, n35, etc). I can't imagine any content where .length() would return harmful code; though I'm not well versed in JS.

libertymcateer 10y ago
I'm also interested to know. Believe it or not, I would love to get Nik as a consultant. I fear my 'hubris' (I won't deny it, this idea is extraordinarily ambitious and I have to be arrogant to even conceive of it) will have pissed him off irrevocably. That aside, I don't really follow his point on the login PW. I understand 8 char alphanum pw is pretty low entropy... but that isn't used for encryption. And the login attempt rate is pretty strictly rate limited. And yes, I am getting professionals - not me - to do the heavy lifting. I wrote the proof of concept. I am in no way surprised to find it has issues - I am aware of a few others myself.
- nikcub 10y ago
  It isn't the login password but the message password - although using sha256 for a login password isn't great either if you're doing aes(plaintext, sha2(password)) = cyphertext given cyphertext I can get to plaintext with sha2(8-char dictionary) well designed systems will generate a truly random key there, exchanged using public-key. if you're going to use a password, you need a key-derivation algorithm this is all bunk tho since the big vulnerability here is that you're delivering the encryption routines via javascript in a global browser space
  - libertymcateer 10y ago
    > this is all bunk tho since the big vulnerability here is that you're delivering the encryption routines via javascript in a global browser space So what about mailvelope?
    - libertymcateer 10y ago