6 ms·

Show HN: Online journal that encrypts entries with a cipher

45 points by dylanbfox 12y ago

dylanbfox 12y ago
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)
- jamestomasino 12y ago
  It's interesting that you chose not to encrypt the titles of the entries. I suppose that's so that it's easier for us to browse back in time and find an entry without having to decrypt them all? Things I noted: - Each entry gets its own passphrase. You could use the same one again or again, or change it up. The addition of a 'hint' is nice. - The title default should clear when you enter it with your tab or mouse focus. That's a minor thing, but annoying. Regarding the keys used in the browser, is it possible to have whatever key phrase we enter also be seeded? That way, if by some miracle your database was compromised, anyone that did happen to use the same key passphrase over and over would have an extra level of protection? (Crypto people out there, does this actually give any additional protection, or am I just piling on unnecessary steps?)
  - dylanbfox 12y ago
    Exactly. Some early feedback from friends said they needed more ways to find entries other than timestamps. Was thinking either titles or tags, and went with titles for now. Maybe I should make it more clear that titles aren't encrypted. It asks you for a new cipher key on every entry, correct. The encryption keys aren't stored. You could use the same cipher key for each entry though, and keep it in some password vault somewhere (maybe even on BitJournal itself). And leave a hint to remind you where the cipher key is.
    - jamestomasino 12y ago
      I really like it, dylanbfox. I think being more explicit on the titles would be a nice thing. My biggest question is where you see the future of this project going. Having a web-based home for my private journaling might be something I'd want, and the crypto seems nice. It does mean that there would never be a social aspect here that would grow a community in that regard. Ad serving for revenue is out because of the security implications. That leaves the question of what your plans are for hosting long term. You said this was a weekend project, and it's great, but if I were to start using this to store private information that I value, what sort of trust could I have that you'd keep the service going? Is it something you'd try to eventually monetize, or is this a candidate for open-sourcing so folks could self-host?
      - jamiesonbecker 12y ago
        I agree. Don't know what commercial plans you had for it, but I'd love to see something exactly like this as an open source single-page JS app that I could run as file:.. (this would help w/ pull reqs too).
        dylanbfox 12y ago
        Thanks! I got a lot of great feedback yesterday that I'm incorporating, which is why I decided to pull the trigger and post to HN in the first place. For now I'm going to keep developing it as much as I can. I don't have any commercial plans. I thought about open sourcing it, and it's something I'm seriously considering. I do plan to host it for a while, but if for whatever reason I were to stop supporting it I would make this clear very far in advance. I should probably talk about this somewhere on the website. I'm sure other people have the same question. If you or anyone else has any other feedback/suggestions, please send it my way! My email is on the "info" page of the site. Thanks again.
    - deleted 12y ago
      [deleted]
- peterwwillis 12y ago
  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.
  - sasas 12y ago
    Exactly my thoughts too. You would have thought that basic xss would be handled [1]. Downright irresponsible to tout a security product without due diligence. [1] http://imgur.com/DKmfic0 http://imgur.com/DKmfic0
  - logicallee 12y ago
    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_ 12y ago
      "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.
- signalsmith 12y ago
  As others have mentioned, the JS for the crypto is fetched from the server every time, which is a weak spot because the server could give you duff crypto code. I've looked at similar things before, and I became very interested in Data URLs. Here's an example that PGP-encrypts files and uploads them to DropBox: https://bitbucket.org/geraintluff/encrypted-drop https://bitbucket.org/geraintluff/encrypted-drop The idea is that you can fit a very small implementation of SHA-256 as inline JavaScript in an HTML page. This means that you can produce a 1500-character Data URL which loads, SHA-256 verifies and executes the external resources needed to bootstrap your app. I started a whole module loader based on this concept, so you could do fancier things like async/parallel loading, adding more verification methods (e.g. public key, once that module is loaded) and so on: https://bitbucket.org/geraintluff/caution.js https://bitbucket.org/geraintluff/caution.js
  - jamiesonbecker 12y ago
    That's pretty slick! (Let's assume that the PRNG in-browser issue is resolved.) Setting far-future expires/forcing long-term caching can help. Even LocalStorage for code can help. Of course, it's still chicken and egg -- and anything can be updated or disabled on the fly w/ HTML anyway at next load. Any of the injection or MITM issues that arise w/ in-browser crypto are similar to those in mobile apps or browser extensions as well, except that you have the chance to modify the app more often, so sticking your crypto code in an app or browser extension is no panacea anyway. Maybe you could combine this concept with http://headjs.com/ http://headjs.com/. It's a great idea.
sbriggman 12y ago
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 12y ago
  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.
iamleppert 12y ago
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.
sasas 12y ago
Obligatory disclaimer: "Javascript Cryptography Considered Harmful" http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/
- chrisfosterelli 12y ago
  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 12y ago
    > 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
    - chrisfosterelli 12y ago
      Desktop crypto applications also suffer from security vulnerabilities, I think the same criticism applies there. Clever XSS by the way ;)
    - jamiesonbecker 12y ago
      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?
desireco42 12y ago
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.
franciscop 12y ago
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_encrypting_twice_is_not_much_better/ http://www.reddit.com/r/crypto/comments/1nhi4m/why_encryptin...
- some_furry 12y ago
  > 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/d5a04a7053597a3d2df0d116efbddd3577aa07af/class.cipher.php#L11 https://github.com/FranciscoP/secretdiary/blob/d5a04a7053597... In your library, you're using ECB mode, with an IV, and not MACing anything...
  - franciscop 12y ago
    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 (;
deleted 12y ago
[deleted]
wepple 12y ago
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).
Dewie 12y ago
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.
bcg1 12y ago
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 12y ago
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 12y ago
  > "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 12y ago
    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.
- jamiesonbecker 12y ago
  It's very rare indeed that I disagree with tptacek. :) But browser-side encryption can be useful to protect against TLS/SSL non-specific MITM. For example, let's say that you're in possession of a compromised root cert and don't want to perform client-side detectable JS injection to remove/minimize the app's encryption functionality.

45 points by dylanbfox 12y ago

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)

jamestomasino 12y ago
It's interesting that you chose not to encrypt the titles of the entries. I suppose that's so that it's easier for us to browse back in time and find an entry without having to decrypt them all? Things I noted: - Each entry gets its own passphrase. You could use the same one again or again, or change it up. The addition of a 'hint' is nice. - The title default should clear when you enter it with your tab or mouse focus. That's a minor thing, but annoying. Regarding the keys used in the browser, is it possible to have whatever key phrase we enter also be seeded? That way, if by some miracle your database was compromised, anyone that did happen to use the same key passphrase over and over would have an extra level of protection? (Crypto people out there, does this actually give any additional protection, or am I just piling on unnecessary steps?)
- dylanbfox 12y ago
  Exactly. Some early feedback from friends said they needed more ways to find entries other than timestamps. Was thinking either titles or tags, and went with titles for now. Maybe I should make it more clear that titles aren't encrypted. It asks you for a new cipher key on every entry, correct. The encryption keys aren't stored. You could use the same cipher key for each entry though, and keep it in some password vault somewhere (maybe even on BitJournal itself). And leave a hint to remind you where the cipher key is.
  - jamestomasino 12y ago
    I really like it, dylanbfox. I think being more explicit on the titles would be a nice thing. My biggest question is where you see the future of this project going. Having a web-based home for my private journaling might be something I'd want, and the crypto seems nice. It does mean that there would never be a social aspect here that would grow a community in that regard. Ad serving for revenue is out because of the security implications. That leaves the question of what your plans are for hosting long term. You said this was a weekend project, and it's great, but if I were to start using this to store private information that I value, what sort of trust could I have that you'd keep the service going? Is it something you'd try to eventually monetize, or is this a candidate for open-sourcing so folks could self-host?
    - jamiesonbecker 12y ago
      I agree. Don't know what commercial plans you had for it, but I'd love to see something exactly like this as an open source single-page JS app that I could run as file:.. (this would help w/ pull reqs too).
      - dylanbfox 12y ago
        Thanks! I got a lot of great feedback yesterday that I'm incorporating, which is why I decided to pull the trigger and post to HN in the first place. For now I'm going to keep developing it as much as I can. I don't have any commercial plans. I thought about open sourcing it, and it's something I'm seriously considering. I do plan to host it for a while, but if for whatever reason I were to stop supporting it I would make this clear very far in advance. I should probably talk about this somewhere on the website. I'm sure other people have the same question. If you or anyone else has any other feedback/suggestions, please send it my way! My email is on the "info" page of the site. Thanks again.
  - deleted 12y ago
    [deleted]
peterwwillis 12y ago
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.
- sasas 12y ago
  Exactly my thoughts too. You would have thought that basic xss would be handled [1]. Downright irresponsible to tout a security product without due diligence. [1] http://imgur.com/DKmfic0 http://imgur.com/DKmfic0
- logicallee 12y ago
  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_ 12y ago
    "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.
signalsmith 12y ago
As others have mentioned, the JS for the crypto is fetched from the server every time, which is a weak spot because the server could give you duff crypto code. I've looked at similar things before, and I became very interested in Data URLs. Here's an example that PGP-encrypts files and uploads them to DropBox: https://bitbucket.org/geraintluff/encrypted-drop https://bitbucket.org/geraintluff/encrypted-drop The idea is that you can fit a very small implementation of SHA-256 as inline JavaScript in an HTML page. This means that you can produce a 1500-character Data URL which loads, SHA-256 verifies and executes the external resources needed to bootstrap your app. I started a whole module loader based on this concept, so you could do fancier things like async/parallel loading, adding more verification methods (e.g. public key, once that module is loaded) and so on: https://bitbucket.org/geraintluff/caution.js https://bitbucket.org/geraintluff/caution.js
- jamiesonbecker 12y ago
  That's pretty slick! (Let's assume that the PRNG in-browser issue is resolved.) Setting far-future expires/forcing long-term caching can help. Even LocalStorage for code can help. Of course, it's still chicken and egg -- and anything can be updated or disabled on the fly w/ HTML anyway at next load. Any of the injection or MITM issues that arise w/ in-browser crypto are similar to those in mobile apps or browser extensions as well, except that you have the chance to modify the app more often, so sticking your crypto code in an app or browser extension is no panacea anyway. Maybe you could combine this concept with http://headjs.com/ http://headjs.com/. It's a great idea.

sbriggman 12y ago

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 12y ago
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.

iamleppert 12y ago

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.

sasas 12y ago

Obligatory disclaimer: "Javascript Cryptography Considered Harmful" http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/

chrisfosterelli 12y ago
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 12y ago
  > 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
  - chrisfosterelli 12y ago
    Desktop crypto applications also suffer from security vulnerabilities, I think the same criticism applies there. Clever XSS by the way ;)
  - jamiesonbecker 12y ago
    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?

desireco42 12y ago

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.

franciscop 12y ago

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_encrypting_twice_is_not_much_better/ http://www.reddit.com/r/crypto/comments/1nhi4m/why_encryptin...

some_furry 12y ago
> 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/d5a04a7053597a3d2df0d116efbddd3577aa07af/class.cipher.php#L11 https://github.com/FranciscoP/secretdiary/blob/d5a04a7053597... In your library, you're using ECB mode, with an IV, and not MACing anything...
- franciscop 12y ago
  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 (;

deleted 12y ago

[deleted]

wepple 12y ago

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

Dewie 12y ago

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.

bcg1 12y ago

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 12y ago

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 12y ago
> "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 12y ago
  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.
jamiesonbecker 12y ago
It's very rare indeed that I disagree with tptacek. :) But browser-side encryption can be useful to protect against TLS/SSL non-specific MITM. For example, let's say that you're in possession of a compromised root cert and don't want to perform client-side detectable JS injection to remove/minimize the app's encryption functionality.