9 ms·

Show HN: InstantCryptor – AES256 Encryption for Dropbox and Google Drive

35 points by licobo 12y ago

licobo 12y ago
A small side project to encrypt files for Dropbox and Google Drive. Encryption happens locally in the browser via JavaScript. The key never leaves the local computer. Happy for any feedback or comments ;)
- moe 12y ago
  Happy for any feedback or comments Don't put your crypto experiments online where they could harm someone who naively relies on them.
  - sarciszewski 12y ago
    Yeah, look what happened when someone leaked Ron Rivest's RC4 cipher. People still naively rely on it!
licobo 12y ago
And we do not store or even transfer your Dropbox or Google password on our servers. It runs locally in your browser. Feel free to double check this in the source code ;)
- ReidZB 12y ago
  Can you link to the source code? In the 2-3 minutes I've spent searching, I can't find it.
  - dreemkilker 12y ago
    If it's all client side JavaScript, then the source code is the webpage.
- wtbob 12y ago
  That's the problem with in-browser crypto, though: you could change the source code at-will. You could even serve different versions of the source code to different people. You might even be compelled by your state to do so, even if you wished not to. Better to deliver the end-user a piece of code he can examine once and trust going forward.
wolf550e 12y ago
>> 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.
sarciszewski 12y ago
Two things: 1. Cryptor is usually the word used by criminals to describe payload obfuscation to evade antivirus detection. 2. Momma says closed-source crypto is the devil.
- ryanlol 12y ago
  1. You're confusing "cryptor" with "crypter" 2. "Closed source" and javascript don't really work together.
  - sarciszewski 12y ago
    I've seen it spelled both ways. Usually on HackForums (a.k.a. the massive script kiddie honeypot).
    - ryanlol 12y ago
      site:hackforums.net cryptor About 1,790 results (0.32 seconds) vs site:hackforums.net crypter About 62,700 results (0.36 seconds)
deleted 12y ago
[deleted]
licobo 12y ago
We are using CBC as block cipher mode. I totally understand that open sourcing the complete code is the only way for you to review it and trust it completely. We decided to write a detailed report about the encryption and how we use it and will publish the report soon via Twitter.
- licobo 12y ago
  via @cloudrail
- diafygi 12y ago
  "We decided to write a detailed report about the encryption and how we use it and will publish the report soon via Twitter." That doesn't sound like releasing the source code...
- tptacek 12y ago
  CBC mode by itself is insecure.
  - sarciszewski 12y ago
    OP: You should listen to tptacek. He's forgotten more about crypto than some people have ever learned. :)
- netheril96 12y ago
  How do you generate the initialization vector? CBC mode requires an unpredictable IV, which usually equals cryptographic random number. > var hash = crc.Crypto.Hash.SHA256.hash(password.value), > crypter = new Crypt.Mode.Licobo(new Crypt.Rijndael256(hash)), From the code I cannot see any generation of IV, so I can only assume that the same IV is used every time. A predictable IV leads to many kinds of attacks. In particular, since the key is generated without salting, this means that a combination of the same key and IV will be used for multiple files, completely defeats the confidentiality. And no integrity protection whatsoever? So vulnerable to bit flipping attacks?
Grazester 12y ago
ooh. I made an app that encrypts files on Android written in Java and has a C# written client for Windows. I have released the java source code. I should post it here on HN to look at it and rip me a new one. What I am sketchy about is how does embedding an unencrypted salt used for the PBKDF2 in the file not potentially make guessing of the passphrase easier
- anacleto 12y ago
  Nice points.
- StavrosK 12y ago
  How are you going to guess the password given just the salt, not even the hash? Hell, even with the hash itself it's nowhere near easy.
- dreemkilker 12y ago
  To answer your question about the the salt and the PBKDF2: salt ensures that the hash of my password is different from someone else's, even if we use the same password (or I use the same password on another site). Thus, if someone has the hashes, and wants to attack the system, then need to attack each password independently (they can't just run a password dictionary through the PKDF2 (or SHA256 in this case - very bad choice)) and then compare the results against all of the password hashes. They have to start with the salt (different for each user), and then run each password guess through the algorithm. Much slower. Much better. Which brings us to PBKDF2 instead of SHA256: SHA256 is designed to be fast. That's bad when hashing passwords, because it makes offline dictionary-based attacks faster. Password Derivation functions are designed to be slow. That makes logging on very slightly slower, but makes offline attacks much, much slower. However, doing the encryption in Javascript is a fatal problem: At any time, they can update (or be forced to update) the javascript to send the server my password when I use it, and the only way I can protect myself from this is to audit the code, EVERY TIME I USE IT.
  - FlorianWendel 12y ago
    Why do you consider unsalted SHA-256 a bad choice here? If neither the password nor its hash are stored and the hash is merely used as a key for the CBC, I don't see how anyone could construct rainbow tables for that. Care to explain?
anacleto 12y ago
This should be released as OpenSource.
mbq 12y ago
Even with proper algorithms, per-file encryption leaks quite a lot of meta-data, sizes and usage patterns; also the cloud provider can transparently delete, corrupt and revert files to previous versions.
- java-man 12y ago
  I wrote a backup/archive tool [0] that uses authenticated encryption, scrypt, and local key management. The only thing it leaks [1] is the amount of new data added on each snapshot. [0] http://goryachev.com/products/secure-archive http://goryachev.com/products/secure-archive [1] hopefully
sobel 12y ago
I've built a similar piece of javascript crypto: PasswordProtectMyFile.com. It's a single HTML page that can work with internet turned off. The ciphertext is another HTML page with all the javascript needed to decrypt itself. It's open source: https://github.com/louissobel/ppmf https://github.com/louissobel/ppmf
java-man 12y ago
An encrypted archive with browsing, revision history, and search: http://goryachev.com/products/secure-archive http://goryachev.com/products/secure-archive
nodata 12y ago
http://syncthing.net/ http://syncthing.net/ open source and transit encrypted between computers you control.
licobo 12y ago
@all: thanks a lot for your feedback! It's good to see that so many people care about security. To quickly summarize your questions: We are using the secure CBC mode and have always used it ;) You can have a look on the source code directly on the website (because it's all client side JavaScript), but some parts of it are minified. We are working on a detailed description of the technology behind InstantCryptor and will publish it soon via Twitter (@cloudrail). If you are interested in the technology to easily add cloud storage into your application visit cloudrail.com to get a free copy.
- jjarmoc 12y ago
  CBC mode is not inherently secure. Details matter and can often introduce catastrophic problems.
- higherpurpose 12y ago
  It seems you have an authentication problem: https://www.grc.com/sn/SN-497-Notes.pdf https://www.grc.com/sn/SN-497-Notes.pdf There should be more details here after the show will be recorded (live now): http://twit.tv/show/security-now/497 http://twit.tv/show/security-now/497 I think using ChaCha20-Poly1305 instead of AES-CBC would solve that problem. https://www.imperialviolet.org/2013/10/07/chacha20.html https://www.imperialviolet.org/2013/10/07/chacha20.html
  - jjarmoc 12y ago
    I don't know that I'd necessary push for ChaCha20, but lack of ciphertext authentication is a clear problem. AES-GCM or even AES-CBC with an HMAC that's validated prior to decryption can provide the needed authenticity checks.

35 points by licobo 12y ago

A small side project to encrypt files for Dropbox and Google Drive. Encryption happens locally in the browser via JavaScript. The key never leaves the local computer. Happy for any feedback or comments ;)

moe 12y ago
Happy for any feedback or comments Don't put your crypto experiments online where they could harm someone who naively relies on them.
- sarciszewski 12y ago
  Yeah, look what happened when someone leaked Ron Rivest's RC4 cipher. People still naively rely on it!

licobo 12y ago

And we do not store or even transfer your Dropbox or Google password on our servers. It runs locally in your browser. Feel free to double check this in the source code ;)

ReidZB 12y ago
Can you link to the source code? In the 2-3 minutes I've spent searching, I can't find it.
- dreemkilker 12y ago
  If it's all client side JavaScript, then the source code is the webpage.
wtbob 12y ago
That's the problem with in-browser crypto, though: you could change the source code at-will. You could even serve different versions of the source code to different people. You might even be compelled by your state to do so, even if you wished not to. Better to deliver the end-user a piece of code he can examine once and trust going forward.

wolf550e 12y ago

>> 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.

sarciszewski 12y ago

Two things: 1. Cryptor is usually the word used by criminals to describe payload obfuscation to evade antivirus detection. 2. Momma says closed-source crypto is the devil.

ryanlol 12y ago
1. You're confusing "cryptor" with "crypter" 2. "Closed source" and javascript don't really work together.
- sarciszewski 12y ago
  I've seen it spelled both ways. Usually on HackForums (a.k.a. the massive script kiddie honeypot).
  - ryanlol 12y ago
    site:hackforums.net cryptor About 1,790 results (0.32 seconds) vs site:hackforums.net crypter About 62,700 results (0.36 seconds)

deleted 12y ago

[deleted]

licobo 12y ago

We are using CBC as block cipher mode. I totally understand that open sourcing the complete code is the only way for you to review it and trust it completely. We decided to write a detailed report about the encryption and how we use it and will publish the report soon via Twitter.

licobo 12y ago
via @cloudrail
diafygi 12y ago
"We decided to write a detailed report about the encryption and how we use it and will publish the report soon via Twitter." That doesn't sound like releasing the source code...
tptacek 12y ago
CBC mode by itself is insecure.
- sarciszewski 12y ago
  OP: You should listen to tptacek. He's forgotten more about crypto than some people have ever learned. :)
netheril96 12y ago
How do you generate the initialization vector? CBC mode requires an unpredictable IV, which usually equals cryptographic random number. > var hash = crc.Crypto.Hash.SHA256.hash(password.value), > crypter = new Crypt.Mode.Licobo(new Crypt.Rijndael256(hash)), From the code I cannot see any generation of IV, so I can only assume that the same IV is used every time. A predictable IV leads to many kinds of attacks. In particular, since the key is generated without salting, this means that a combination of the same key and IV will be used for multiple files, completely defeats the confidentiality. And no integrity protection whatsoever? So vulnerable to bit flipping attacks?

Grazester 12y ago

ooh. I made an app that encrypts files on Android written in Java and has a C# written client for Windows. I have released the java source code. I should post it here on HN to look at it and rip me a new one. What I am sketchy about is how does embedding an unencrypted salt used for the PBKDF2 in the file not potentially make guessing of the passphrase easier

anacleto 12y ago
Nice points.
StavrosK 12y ago
How are you going to guess the password given just the salt, not even the hash? Hell, even with the hash itself it's nowhere near easy.
dreemkilker 12y ago
To answer your question about the the salt and the PBKDF2: salt ensures that the hash of my password is different from someone else's, even if we use the same password (or I use the same password on another site). Thus, if someone has the hashes, and wants to attack the system, then need to attack each password independently (they can't just run a password dictionary through the PKDF2 (or SHA256 in this case - very bad choice)) and then compare the results against all of the password hashes. They have to start with the salt (different for each user), and then run each password guess through the algorithm. Much slower. Much better. Which brings us to PBKDF2 instead of SHA256: SHA256 is designed to be fast. That's bad when hashing passwords, because it makes offline dictionary-based attacks faster. Password Derivation functions are designed to be slow. That makes logging on very slightly slower, but makes offline attacks much, much slower. However, doing the encryption in Javascript is a fatal problem: At any time, they can update (or be forced to update) the javascript to send the server my password when I use it, and the only way I can protect myself from this is to audit the code, EVERY TIME I USE IT.
- FlorianWendel 12y ago
  Why do you consider unsalted SHA-256 a bad choice here? If neither the password nor its hash are stored and the hash is merely used as a key for the CBC, I don't see how anyone could construct rainbow tables for that. Care to explain?

anacleto 12y ago

This should be released as OpenSource.

mbq 12y ago

Even with proper algorithms, per-file encryption leaks quite a lot of meta-data, sizes and usage patterns; also the cloud provider can transparently delete, corrupt and revert files to previous versions.

java-man 12y ago
I wrote a backup/archive tool [0] that uses authenticated encryption, scrypt, and local key management. The only thing it leaks [1] is the amount of new data added on each snapshot. [0] http://goryachev.com/products/secure-archive http://goryachev.com/products/secure-archive [1] hopefully

sobel 12y ago

I've built a similar piece of javascript crypto: PasswordProtectMyFile.com. It's a single HTML page that can work with internet turned off. The ciphertext is another HTML page with all the javascript needed to decrypt itself. It's open source: https://github.com/louissobel/ppmf https://github.com/louissobel/ppmf

java-man 12y ago

An encrypted archive with browsing, revision history, and search: http://goryachev.com/products/secure-archive http://goryachev.com/products/secure-archive

nodata 12y ago

http://syncthing.net/ http://syncthing.net/ open source and transit encrypted between computers you control.

licobo 12y ago

@all: thanks a lot for your feedback! It's good to see that so many people care about security. To quickly summarize your questions: We are using the secure CBC mode and have always used it ;) You can have a look on the source code directly on the website (because it's all client side JavaScript), but some parts of it are minified. We are working on a detailed description of the technology behind InstantCryptor and will publish it soon via Twitter (@cloudrail). If you are interested in the technology to easily add cloud storage into your application visit cloudrail.com to get a free copy.

jjarmoc 12y ago
CBC mode is not inherently secure. Details matter and can often introduce catastrophic problems.
higherpurpose 12y ago
It seems you have an authentication problem: https://www.grc.com/sn/SN-497-Notes.pdf https://www.grc.com/sn/SN-497-Notes.pdf There should be more details here after the show will be recorded (live now): http://twit.tv/show/security-now/497 http://twit.tv/show/security-now/497 I think using ChaCha20-Poly1305 instead of AES-CBC would solve that problem. https://www.imperialviolet.org/2013/10/07/chacha20.html https://www.imperialviolet.org/2013/10/07/chacha20.html
- jjarmoc 12y ago
  I don't know that I'd necessary push for ChaCha20, but lack of ciphertext authentication is a clear problem. AES-GCM or even AES-CBC with an HMAC that's validated prior to decryption can provide the needed authenticity checks.