
Show HN: Online journal that encrypts entries with a cipher - dylanbfox
https://www.bitjournal.io
======
dylanbfox
Author here. This was a weekend project I've been working on. It's very much
in beta.

I'm using SJCL
([https://crypto.stanford.edu/sjcl/](https://crypto.stanford.edu/sjcl/)) and
CryptoJS ([https://code.google.com/p/crypto-
js/](https://code.google.com/p/crypto-js/)) for client-side encryption, and
Python's Cryptography library
([https://cryptography.io/en/latest/](https://cryptography.io/en/latest/)) for
back-end encryption.

Would love some feedback. Since it's in beta, signups are limited but you can
use "hackernews500" as an early access code to sign up now if you want to
check it out.

Thanks!

EDIT (PS - It's not mobile friendly yet, so you'll probably run into some UI
issues on mobile devices)

~~~
peterwwillis
Feedback:

Browser crypto is unreliable. This has been debated to death, but here's a
plain and simple fact: Your project delivers crypto software via your website
to the user's browser, so this connection is absolutely critical for your site
to be worth anything at all. And yours is not secure.

First off, your root domain has no SSL server
([https://bitjournal.io/](https://bitjournal.io/)), so it's vulnerable to HSTS
hijacking. Basically, if you use HSTS, someone can MITM the initial connection
to [http://bitjournal.io/](http://bitjournal.io/) every time because you don't
have an SSL server on that hostname to negotiate HSTS. Fix: set up HSTS and an
HTTP redirect on [http://bitjournal.io/](http://bitjournal.io/) to
[https://bitjournal.io/](https://bitjournal.io/), set up HSTS and an HTTP
redirect on [http://www.bitjournal.io/](http://www.bitjournal.io/) to
[https://www.bitjournal.io/](https://www.bitjournal.io/), and then HTTP
redirect from [https://bitjournal.io/](https://bitjournal.io/) to
[https://www.bitjournal.io/](https://www.bitjournal.io/).

Slightly more pressing problem: you aren't using HSTS at all. Anyone can mitm
your site and screw with your users.

Additional problem: your SSL site supports weak encryption, and is potentially
vulnerable to secure renegotiation DoS.

My suggestion is to do a lot more research into security in general before you
get into making crypto software. You can fix the problems I mention above in a
weekend, but that doesn't mean you won't make other mistakes which could
expose your users' private data.

~~~
logicallee
gee, I'd hate to see what you have to say to the guy in this thread who made
secretdiary.org which "was basically the same idea but implemented server-
side", using php.

in other words, relax, this is obviously a joke and not actually meant to be
secure in any way, shape, or form.

~~~
akerl_
"Keep your thoughts, ideas, and other confidential information protected from
prying eyes with your own BitJournal. Each entry is encrypted with a symmetric
key cipher, and only you have the key."

Hopefully the author can comment, but this doesn't look like a joke.

------
bcg1
I'm not being negative or sarcastic, but what is the purpose of this?

If I was concerned about secrecy or privacy, why is this better than just
using some regular encryption tools and some "cloud drive" or
whateveryoumightcallit?

I appreciate that this is a weekend project (and by the way it looks nice) so
I'm not trying to beat it up, but its a big leap from a project for scratching
your own itch to inviting others to give you their sensitive data (encrypted
or not) with a promise of security.

At the very least you might want to publish a terms of service and privacy
policy. A warrant canary might be nice as well.

PS - I have a spectacular ability to make an ass of myself, so if my
criticisms come off as rude or are unwarranted, I truly apologize.

------
tptacek
I'll let someone else rant about browser Javascript encryption (it serves
essentially no security purpose), but instead just comment to say that
"AES-256 in CBC mode" is not a confidence-inspiring description of a
cryptosystem.

Have you published the Javascript code you used for this anywhere? Can we see
it? I was going to peek at it, but would apparently need to register for the
site to do that.

You might consider hoisting your SJCL crypto code out of the DOM and sticking
it in a Chrome extension.

~~~
some_furry
> "AES-256 in CBC mode" is not a confidence-inspiring description of a
> cryptosystem

I'll second this, although knowing the author, my concurrence doesn't add much
weight.

To wit:

    
    
        * Encryption is not authentication. CBC mode in particular is vulnerable to 
          bit-flipping attacks.
        * The password KDF is an important implementation detail that needs to be 
          considered.
        * Browser extensions and node-webkit > browser JS
    

OP: Let me know if you'd like to know more about these details and/or advice
on moving forward.

~~~
dylanbfox
Hey thanks for the feedback! I go into more detail on the "info" page. Wasn't
sure if I should include the entire description on the home page or not.

I'd love all the feedback I can get. That's exactly why I wanted to post it to
HN today. I'll follow you on Twitter and DM you my email.

------
franciscop
Hello, I created some time ago
[http://secretdiary.org/](http://secretdiary.org/) [now deleted]. It was
basically the same idea but implemented server-side since that was what I
wanted to learn at the moment, using the encryption MCRYPT_RIJNDAEL_256 from
PHP [1]

I think that the double encryption is not needed, but since I am not an expert
(just an enthusiast) I dig in the past about it and the experts and
enthusiasts say the same [2][3]

I just re-bought the name so that no one could buy it when I made it public.
If you want it, I have no problem in giving it for free since it reminds me a
lot to my project and I think the name could be more suitable and you _are_
indeed much more advanced that my project ever was and actively developing it
(:

[1]
[https://github.com/FranciscoP/secretdiary](https://github.com/FranciscoP/secretdiary)

[2]
[http://security.stackexchange.com/a/32260/9161](http://security.stackexchange.com/a/32260/9161)

[3]
[http://www.reddit.com/r/crypto/comments/1nhi4m/why_encryptin...](http://www.reddit.com/r/crypto/comments/1nhi4m/why_encrypting_twice_is_not_much_better/)

~~~
some_furry
> MCRYPT_RIJNDAEL_256

I hope you realize this isn't AES-256.

I strongly encourage you and anyone else who wants to play with encryption in
PHP to just use [https://github.com/defuse/php-
encryption](https://github.com/defuse/php-encryption)

Also, encryption isn't authentication. You'll probably quickly hear about
Moxie Marlinspike's Cryptographic Doom Principle from others. Basically it
means that you should be authenticating your ciphertexts.

Welcome to crypto, a lot can go wrong and some people have very strong
opinions about it.

I highly recommend taking the time to go through the challenges on
cryptopals.com (by the fine folks at Matasano) and learn more about it. :)

EDIT:

[https://github.com/FranciscoP/secretdiary/blob/d5a04a7053597...](https://github.com/FranciscoP/secretdiary/blob/d5a04a7053597a3d2df0d116efbddd3577aa07af/class.cipher.php#L11)

In your library, you're using ECB mode, with an IV, and not MACing anything...

~~~
franciscop
It was one of my first projects and the first time I did anything with
cryptography. I expected it to have some security holes but discontinued it
for lack of time, I was just offering the domain here (;

~~~
some_furry
Understood. If you're interested in learning more about crypto I encourage you
to check cryptopals out :)

------
sasas
Obligatory disclaimer: "Javascript Cryptography Considered Harmful"

[http://matasano.com/articles/javascript-
cryptography/](http://matasano.com/articles/javascript-cryptography/)

~~~
chrisfosterelli
This article gets posted a lot. The author seems to provide two scenarios:
either you use SSL/TLS and don't need Javascript encryption or you use
Javascript encryption and are open to side-channel attacks. He briefly covers
the idea of using both, then hand-wavily disregards it.

He has many valid points, but serving Javascript encryption code over SSL/TLS
and using it to keep your privacy in the server's DB is _still a good idea_.
Do you have to trust the server a reasonable amount because of the fact that
they could change their JS at any time? Yes. Does that make encryption useless
and not worth doing? No.

I'd also like to point out that there are alternatives to this where you don't
have to trust the server after verifying the code the first time, see
Substack's demo here: [http://hyperboot.org/](http://hyperboot.org/)

JS encryption does have weak spots that could be improved, but that's not
going to happen by completely refusing any sort of JS encryption as useless.

~~~
sasas
> Do you have to trust the server a reasonable amount because of the fact that
> they could change their JS at any time?

What if it's not the server's JS? -

[http://imgur.com/DKmfic0](http://imgur.com/DKmfic0)

~~~
jamiesonbecker
Agreed.. but XSS (or MITM injection) isn't a scalable activity. You'd have to
write it custom for each app. Even if you just attacked the underlying
library, it's still something that's detectable on the browser side, so you'd
have to carefully target your opponent (unless you just didn't care if they
knew at all -- but that'd minimize your effectiveness as well.)

IMO, it's definitely worthwhile at least the initial crypto stage in-browser.
Heartbleed et al proved that. Just don't rely on it. Ensure strong TLS, HSTS,
etc as well.

Definitely agreed - XSS is really severely problematic since it's potentially
easier and doesn't require MITM. In this rare use case (and without actually
trying the app), I'm guessing you'd basically have to be XSS'ing yourself
since you're probably not XSS'ing a public field?

------
iamleppert
This is cool, but all that it takes to break down the fancy encryption is for
the government/law enforcement to take it over and add some tiny js in the
page.

If you really need to be secure, never trust a third party.

------
desireco42
I can't see myself using this for journal, simply having a usb or some other
way is preferable if I need privacy. However, this has potential as a very
nice solution for encrypting entries of any kind. Some kind of secure
evernote. Anyhow, if you decide to further develop, I think this can grow into
very interesting solution.

------
wepple
Just curious, why the double encryption? if I trust the client-side encryption
(thats a whole other discussion) then the server-side is redundant. If I don't
trust the client-side encryption, I'm entrusting all my security to your
second round of encryption (and, you).

------
sbriggman
Very cool project! Would be interesting if you did something along the lines
of facebook - asking a user to recognize a photo of friends after they connect
their facebook account as an alternate encryption method. My bank also allows
the upload of an image, which you need to choose and it's paired with the
password.

~~~
chrisfosterelli
Are you sure you're not thinking of a "security image"? That's a common tactic
by banks to help users feel more secure, but in practice it actually provides
_very_ little benefit.

------
Dewie
I'd rather keep any personal journal/diary offline.

Even if Web technology was trustworthy in itself, I'd have to learn about
exactly what is safe to do in a browser, if I trust the website itself and if
I trust the person/entity/company behind the website. That is a _lot_ of
things to learn and be wary of for just being able to write a diary online.

A personal diary is the most private and uncensored thing that I could write.
I would never consider adding any more complexity to the question of "is this
really for my eyes only?".

It might be fine for something like a technical journal though.

