Provide elliptic curve options

[soygul]

http://www.keylength.com/en/3/

Need to research if work factor in validation is less for ECDSA 256 key vs RSA 3248 key. Gmail uses this so should be safe for mass browser support also.

On the other hand, ECDSA requires a "true" random number generator as opposed to crypto/rand package which is a pseudorandom number generator. However we can combine crypto/rand with entropy generated by the incoming request (IP, request time, time spent on internal queue, load balancing route, handling server no, cpu mem usage for request, etc. etc.) to generate enough randomness for this purpose.

At this point, I'm not 100% sure if we should hash than XOR crypto/rand with other randomness or there is a more secure way.

---

Note: Amongst all elliptic curve parameters, this seems to be the contender with least likelihood of being compromised by certain standards institutes! https://godoc.org/golang.org/x/crypto/curve25519

---

Note 2: Sample ECDSA can be found at: http://golang.org/src/crypto/tls/generate_cert.go

---

Note 3: Also evaluate AEAD ciphers: https://blog.cloudflare.com/go-crypto-bridging-the-performance-gap/ which is not extracted as a stand-alone lib here rather than a full golang clone here: https://github.com/glycerine/fast-elliptic-curve-p256

[soygul]

Disabling RDRAND would also be beneficial as it can not be audited to be non-malicious. Linux /dev/random generates true randomness (as opposed to /dev/urandom which resorts to pseudo-randomness if rand pools runs out of bits). If it is possible to set crypto/rand to use /dev/random only, it might be ok to use ECDSA only.