31–40 of 52 posts
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 ;)
Can you link to the source code? In the 2-3 minutes I've spent searching, I can't find it.
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
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
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.
>> 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?
(I went and checked NaCl and it has its own primitives, http://nacl.cr.yp.to/secretbox.html)
>> 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?
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.
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.
[0] http://goryachev.com/products/secure-archive
[1] hopefully
>> 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?
This appears to be the source code: https://instantcryptor.com/js/main.js
>> 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?
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 )
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-0...
1 - https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305...
2 - https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly130...
3 - https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-t...