10 ms·

>> The password will be hashed with the SHA256 algorithm, the mode for encryption is 256 Bit Rijndael/AES SHA256 is not a KDF, AES-256 is not a block cipher mo

>> The password will be hashed with the SHA256 algorithm, the mode for encryption is 256 Bit Rijndael/AES SHA256 is not a KDF, AES-256 is not a block cipher mode. Where is the source code?

steakejjs 12y ago
Wolf is 100% correct. These details make it sound like this product is insecure. We definitely don't want ecb mode or a weak kdf like 1 round of sha256 with no salt. BUT before anyone lambasts this guy, it's good the author posted so mistakes can be learned from the feedback, that way others get exposed to the issues, and less mistakes are made in the future. In my opinion, there is too much hate for people who make mistakes when writing code, when in reality that's how you learn. Few people learn all the theory first and THEN how to build it, it's often learn to build then the theory.
- moe 12y ago
  This is true for every kind of software except security things. It's really hard for a novice to find something that will actually protect them in between all the "convenient cloud solutions" that an intern cobbled together in their lunch break using some javascript they found on github.
  - steakejjs 12y ago
    No it is even true for security things BUT the authors need to have no problem taking a dose of humble pie and labeling the project as completely insecure. I don't see anything wrong with writing security software that is insecure as long as you don't pretend it is secure....
    - moe 12y ago
      I don't see anything wrong with writing security software that is insecure as long as you don't pretend it is secure.... Except this one very much pretends to offer protection, apparently oblivious of the problems with their design. They should point out very visibly that this is a tech-demo to promote a completely different product, and not an app that anyone should actually use.
  - erglkjahlkh 12y ago
    I wish it were just interns... Example follows. The Finnish security company F-Secure revealed a secure cloud service, called Younited (https://www.younited.com/ https://www.younited.com/). It did not catch on. The active user amounts stayed at near zero level so it was sold to a company called Synchronoss. F-Secure initially hoped that their good reputation, and the fact that the servers are located in countries without draconian spying legislation would be enough. They seriously hoped to make a star product out of their secure cloud service. Well, secure against whom? Simply installing the applications and completing registration process revealed instantly that the service is insecure. Yes, in compliance sense "everything is encrypted", but the keys are clearly held server side. The customer has absolutely no control over the key management and storage, meaning they are at F-Secure's mercy, and F-Secure can technically open everything for authorities. Now the actually interesting part of the story: The problem isn't the implementation. The problem isn't that they marketed it as secure. The important alpha users on this product area are way too savvy, and stayed away. As per the standard innovation diffusion model, they did not drag other users in. Not marketing the service as secure would have yielded better results! It's funny how even serious software security companies screw things up. Even when they are attempting for a strategic new product positioning, and even when at near clear blue sea situation.
  - jszymborski 12y ago
    Why not just use NaCl or libsodium... no need to muck about implementing things you don't fully understand.
ReidZB 12y ago
I really dislike when companies say it their product encrypts with "256-bit encryption" or "AES-256". Like you said, that is an incomplete description of an encryption scheme. The choice of block cipher mode can immediately make or break my opinion of a product, and when developers omit what mode they've chosen, I lean toward break.
- higherpurpose 12y ago
  At least it's not "military-grade encryption".
- dunham 12y ago
  Heh, that reminds me of when the "Trillian" IM client advertised "128-bit blowfish" encryption, but used 128-bit DH to negotiate the key (this many years ago).
TillE 12y ago
PBKDF2 is still the gold standard for converting a password to an encryption key, right? bcrypt has some desirable properties, but it has a fixed output length of 192 bits.
- wolf550e 12y ago
  scrypt is the gold standard, I think.
pjc50 12y ago
What's the standard for this kind of thing, PBKDF2 / AES-CBC / HMAC-256? (I went and checked NaCl and it has its own primitives, http://nacl.cr.yp.to/secretbox.html http://nacl.cr.yp.to/secretbox.html)
- wolf550e 12y ago
  The old best practice was RSA (with OAEP padding), AES CBC (with PKCS 7 padding), HMAC-SHA-2 (for TLS, AES GCM is better than AES CBC + HMAC, but I don't know if it's true in general). The new best practice seems to be something based on Curve25519 with SALSA/XSALSA/CHACHA + POLY1305. CFRG has been trying for a year to come up with recommendation for TLS 1.3 on how to use 25519 and stronger curves in better primitives than ECDSA. ChaCha20+Poly1305 is getting more progress getting standardized, but still very slowly[0][1][2][3]. If you want to be sane then don't look into how sausages, laws and standards get made. 0 - https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-0... 1 - https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305-06 https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305... 2 - https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-10 https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly130... 3 - https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-03 https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-t...
- jedisct1 12y ago
  Scrypt for key derivation, chacha20+poly1305 for authenticated secret-key encryption. In Javascript, https://github.com/jedisct1/libsodium.js https://github.com/jedisct1/libsodium.js provides them.
placeybordeaux 12y ago
Looks like they are using CBC block cipher mode. Guess they updated the site since then. This appears to be the source code: https://instantcryptor.com/js/main.js https://instantcryptor.com/js/main.js
- moe 12y ago
  var hash = crc.Crypto.Hash.SHA256.hash(password.value) crypter = new Crypt.Mode.Licobo(new Crypt.Rijndael256(hash)) And it looks like they didn't bother to use a KDF. But I guess when your mode is "Crypt.Mode.Licobo" then that is the least of your problems...

>> The password will be hashed with the SHA256 algorithm, the mode for encryption is 256 Bit Rijndael/AES SHA256 is not a KDF, AES-256 is not a block cipher mode. Where is the source code?

steakejjs 12y ago

Wolf is 100% correct. These details make it sound like this product is insecure. We definitely don't want ecb mode or a weak kdf like 1 round of sha256 with no salt. BUT before anyone lambasts this guy, it's good the author posted so mistakes can be learned from the feedback, that way others get exposed to the issues, and less mistakes are made in the future. In my opinion, there is too much hate for people who make mistakes when writing code, when in reality that's how you learn. Few people learn all the theory first and THEN how to build it, it's often learn to build then the theory.

moe 12y ago
This is true for every kind of software except security things. It's really hard for a novice to find something that will actually protect them in between all the "convenient cloud solutions" that an intern cobbled together in their lunch break using some javascript they found on github.
- steakejjs 12y ago
  No it is even true for security things BUT the authors need to have no problem taking a dose of humble pie and labeling the project as completely insecure. I don't see anything wrong with writing security software that is insecure as long as you don't pretend it is secure....
  - moe 12y ago
    I don't see anything wrong with writing security software that is insecure as long as you don't pretend it is secure.... Except this one very much pretends to offer protection, apparently oblivious of the problems with their design. They should point out very visibly that this is a tech-demo to promote a completely different product, and not an app that anyone should actually use.
- erglkjahlkh 12y ago
  I wish it were just interns... Example follows. The Finnish security company F-Secure revealed a secure cloud service, called Younited (https://www.younited.com/ https://www.younited.com/). It did not catch on. The active user amounts stayed at near zero level so it was sold to a company called Synchronoss. F-Secure initially hoped that their good reputation, and the fact that the servers are located in countries without draconian spying legislation would be enough. They seriously hoped to make a star product out of their secure cloud service. Well, secure against whom? Simply installing the applications and completing registration process revealed instantly that the service is insecure. Yes, in compliance sense "everything is encrypted", but the keys are clearly held server side. The customer has absolutely no control over the key management and storage, meaning they are at F-Secure's mercy, and F-Secure can technically open everything for authorities. Now the actually interesting part of the story: The problem isn't the implementation. The problem isn't that they marketed it as secure. The important alpha users on this product area are way too savvy, and stayed away. As per the standard innovation diffusion model, they did not drag other users in. Not marketing the service as secure would have yielded better results! It's funny how even serious software security companies screw things up. Even when they are attempting for a strategic new product positioning, and even when at near clear blue sea situation.
- jszymborski 12y ago
  Why not just use NaCl or libsodium... no need to muck about implementing things you don't fully understand.

ReidZB 12y ago

I really dislike when companies say it their product encrypts with "256-bit encryption" or "AES-256". Like you said, that is an incomplete description of an encryption scheme. The choice of block cipher mode can immediately make or break my opinion of a product, and when developers omit what mode they've chosen, I lean toward break.

higherpurpose 12y ago
At least it's not "military-grade encryption".
dunham 12y ago
Heh, that reminds me of when the "Trillian" IM client advertised "128-bit blowfish" encryption, but used 128-bit DH to negotiate the key (this many years ago).

TillE 12y ago

PBKDF2 is still the gold standard for converting a password to an encryption key, right? bcrypt has some desirable properties, but it has a fixed output length of 192 bits.

wolf550e 12y ago
scrypt is the gold standard, I think.

pjc50 12y ago

What's the standard for this kind of thing, PBKDF2 / AES-CBC / HMAC-256? (I went and checked NaCl and it has its own primitives, http://nacl.cr.yp.to/secretbox.html http://nacl.cr.yp.to/secretbox.html)

wolf550e 12y ago
The old best practice was RSA (with OAEP padding), AES CBC (with PKCS 7 padding), HMAC-SHA-2 (for TLS, AES GCM is better than AES CBC + HMAC, but I don't know if it's true in general). The new best practice seems to be something based on Curve25519 with SALSA/XSALSA/CHACHA + POLY1305. CFRG has been trying for a year to come up with recommendation for TLS 1.3 on how to use 25519 and stronger curves in better primitives than ECDSA. ChaCha20+Poly1305 is getting more progress getting standardized, but still very slowly[0][1][2][3]. If you want to be sane then don't look into how sausages, laws and standards get made. 0 - https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-0... 1 - https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305-06 https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305... 2 - https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-10 https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly130... 3 - https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-03 https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-t...
jedisct1 12y ago
Scrypt for key derivation, chacha20+poly1305 for authenticated secret-key encryption. In Javascript, https://github.com/jedisct1/libsodium.js https://github.com/jedisct1/libsodium.js provides them.

placeybordeaux 12y ago

Looks like they are using CBC block cipher mode. Guess they updated the site since then. This appears to be the source code: https://instantcryptor.com/js/main.js https://instantcryptor.com/js/main.js

moe 12y ago
var hash = crc.Crypto.Hash.SHA256.hash(password.value) crypter = new Crypt.Mode.Licobo(new Crypt.Rijndael256(hash)) And it looks like they didn't bother to use a KDF. But I guess when your mode is "Crypt.Mode.Licobo" then that is the least of your problems...