
Show HN: InstantCryptor – AES256 Encryption for Dropbox and Google Drive - licobo
https://instantcryptor.com/index.html
======
wolf550e
>> 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?

~~~
ReidZB
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
At least it's not "military-grade encryption".

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

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

------
sobel
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)

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

~~~
tptacek
CBC mode by itself is insecure.

~~~
sarciszewski
OP: You should listen to tptacek. He's forgotten more about crypto than some
people have ever learned. :)

------
licobo
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
_Happy for any feedback or comments_

Don't put your crypto experiments online where they could harm someone who
naively relies on them.

~~~
sarciszewski
Yeah, look what happened when someone leaked Ron Rivest's RC4 cipher. People
still naively rely on it!

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

------
java-man
An encrypted archive with browsing, revision history, and search:

[http://goryachev.com/products/secure-
archive](http://goryachev.com/products/secure-archive)

------
licobo
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
Can you link to the source code? In the 2-3 minutes I've spent searching, I
can't find it.

~~~
dreemkilker
If it's all client side JavaScript, then the source code is the webpage.

------
nodata
[http://syncthing.net/](http://syncthing.net/) open source and transit
encrypted between computers you control.

------
sarciszewski
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
1\. You're confusing "cryptor" with "crypter"

2\. "Closed source" and javascript don't really work together.

~~~
sarciszewski
I've seen it spelled both ways. Usually on HackForums (a.k.a. the massive
script kiddie honeypot).

~~~
ryanlol
site:hackforums.net cryptor About 1,790 results (0.32 seconds)

vs

site:hackforums.net crypter About 62,700 results (0.36 seconds)

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

~~~
dreemkilker
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
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
This should be released as OpenSource.

