SHA256 is not a KDF, AES-256 is not a block cipher mode. Where is the source code?

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.

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.

The Finnish security company F-Secure revealed a secure cloud service, called Younited (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.

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.

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

This appears to be the source code: https://instantcryptor.com/js/main.js

  var hash = crc.Crypto.Hash.SHA256.hash(password.value)
  crypter = new Crypt.Mode.Licobo(new Crypt.Rijndael256(hash))

But I guess when your mode is "Crypt.Mode.Licobo" then that is the least of your problems...

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

I think using ChaCha20-Poly1305 instead of AES-CBC would solve that problem.

https://www.imperialviolet.org/2013/10/07/chacha20.html

It's open source: https://github.com/louissobel/ppmf

That doesn't sound like releasing the source code...

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

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

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

[1] hopefully

http://goryachev.com/products/secure-archive

Better to deliver the end-user a piece of code he can examine once and trust going forward.

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.

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

vs

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

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.