Hacker News Reader

Hacker News

Comment by Canada | Hacker News Reader

Full thread

Canada

I have a suggestion: Put a demo on your web site.

edit: Another suggestion... use a proper source of random numbers in init_aes_key_iv(). Using the time isn't good.

View on HN

We are working on it. We didn't anticipate the demand. Give us an hour or so.

Live demo has been posted! Go to the envelope.xyz website or click here:

http://demo.envelope.xyz/

I apologize for the certificate errors. If you want the cert its here: https://demo.envelope.xyz/certificate/index.html

It's a demo. Why are you using SSL?

Perhaps they default to SSL for everything. The certificate error might be annoying, but why encourage devs to not use SSL from the beginning?

Sure, great if you configure it correctly.

Just to make sure, is the demo supposed to forward me to https://postgres.demo.envelope.xyz/v1/app/all/index.html? I feel sheepish for asking for this but a TodoMVC would be really helpful, since I'm not sure what I'm seeing in this demo . The idea sounds very attractive though.

We are going to do a video demo of a complete app on Monday. Should be posted in the afternoon. Thank you for your feedback.

We moved to:

    time(NULL) * getpid() * clock()

Thanks!

That's still not a good idea. Use your OS' random source.

We wanted to avoid anything controversial. Do we need to make this configurable to make everyone happy?

https://www.schneier.com/blog/archives/2013/10/insecurities_...

Even if it isn't perfect /dev/random is a hell of a lot more random than just taking the current time stamp and PID.

Edit: For reference, this is exactly how the Netscape's original SSL implementation was broken: https://web.archive.org/web/20141214141822/http://www.cs.ber...

Understood. Working on it now.

Fixed!

Still weak. Read the seed value from /dev/urandom or get it from CryptGenRandom if you're on Windows.

I think it's also best to use #ifdef to prevent those hardcoded debugging keys from being included in production builds. That is, if you still need to keep them at all.

edit:

joelthelion: You are mistaken. It's not the 1990s anymore. Use the non-blocking /dev/urandom, not /dev/random. (I can't seem to reply directly to you)

/dev/random, not /dev/urandom, if I'm not mistaken.

That's somewhat debatable: http://www.2uo.de/myths-about-urandom/ But really either will be way better than anything you could homebrew.

(EDIT: I reread this and it sounds like I'm ranting at you. Sorry, I'm not, even though it does read like that.)

This is why cryptography is doomed to fail.

This /dev/random vs /dev/urandom (blocking vs non-blocking and whether it matters) is discussed frequently on HN, usually with very long threads, and yet it still comes up.

If I want to remember whether there's an apostrophe in possessive its there's a cartoon to tell me. We need a good, accurate, fact-checked cartoon for urandom vs random.

(It's one of the things I'd do if I had FU money.)

That is truly a horrible seed. Use /dev/random

I just made it so that it uses the first 4 bytes it gets from /dev/random, if it can't open /dev/random, it falls back to what we had before. --nunzio

Don't fall back. If you don't have a reasonable enough environment to get a PRNG, you should halt and complain very loudly.

As for actually generating random numbers, here's a good explanation from 'tptacek: http://sockpuppet.org/blog/2014/02/25/safely-generate-random...

I have finished the error message and pushed to Github. Thank you for your input. I will look at the link you have referenced soon. --nunzio

Use /dev/urandom instead of /dev/random See http://www.2uo.de/myths-about-urandom/ for the reasons

Reply on news.ycombinator.com