What is this site about?
This site contains custom generated Diffie-Hellman parameters with different sizes. These parameters take some time to be generated, keys larger than 4096 bits often takes several hours to be done. Sysadmins do not like to wait hours, but using common DH keys can be a security concern. We help this situation with thousands of pre-generated keys for public use. We hope this helps to protect against unknown attacks by state-backed actors who might have the potential to influence DH parameter selection or who are possibly capable to elaborate attacks against commonly used DH parameters.
What is Diffie-Hellman parameter?
Diffie-Hellman parameters are often used for key exchange in internet cryptographic protocols. If you start a new VPN connection, if you download an SSL webpage, there is a high chance, that D-H parameters are used to make a new secure communications cryptographic key. In one breaks the D-H key exchange (e.g. if the D-H parameter can be attacked), then the attacker can probably access the communication key and hence, the whole encryption might be broken rendering your secure, confidential channel prone to decryption.
How DH parameters are currently used?
In most cases, D-H parameters are fixed values (e.g. in some VPN solutions), or they should be generated by the user if he wants to do so. Most people do not execute D-H parameter generation as it takes too much time. So in most cases D-H parameters are the same for many thousands or millions of devices. This does not mean that these parameters are bad, but nobody knows how big stakeholders, state backed authorities can play with the fact that these parameters are common for many devices.
Why is it important to use individually generated DH parameters?
As we noted, nobody is sure what is possible for big players, state-backed services to play with D-H parameters. If they have any ability to “crack” one connection based with one parameters used by millions, then they are currently able decrypt millions of connections daily. However, publicly no one knows their capability. No one knows what is the safe bitlength for D-H parameters. Generally, people consider that 1024 bits DH generators are not safe, 2048 bits might be safe, but most likely, larger sizes should be considered. Also, generally speaking, most people consider 4096 bits or more as a secure size. Again, there are no real facts to underline these ideas.
Read this related article.
But I can generate DH parameters from DSA stuff faster or I can use ECDHA instead.
Yes, you can. But it has some implications you should consider. We focus here on traditional DH parameter generation. Traditional D-H protocol is used widely, we focus on this, by traditional D-H parameter generation technique.
How to get a DH parameter for my goals?
You can download Diffie-Hellman parameters from our webpage. Our API is very simple. Making a HTTP request to http://www.dhpdb.com/getone.php?bitmin=<number>
will give you back parameters with minimum size specified as <number> and some metadata, like creation time.
Parameters to be used
bitmin: minimum number of bits of the size of the keybitmax: maximum number of bits of the size of the keysilent: return only the parameter without any metadata- other parameters: already made some, but will be introduced based on future requests and feedbacks
Can I use this site for my commercial goals?
This service is made for individuals for using our service rarely for their non-commercial or commercial goals, but surely not for those who want to use it for their deployment services, or to obtain tens or hundreds of pieces daily. So the usage is permitted for non-commercial use, or for those who do not use the service more than two times daily for their whole company infrastructure.
If you want more, please contact us. We’d also be happy to generate private parameters for you that can be commercialized under commercial contract.
How are these parameters on this site have been generated?
For generating the parameters above we did not use any special solution. D-H parameter were generated by openssl, and have been verified by the same software package. Random number generation for the openssl was traditional linux RNG. We think, these solutions cannot be compromised by so big manner that it is not working all the time. In contrast, we tried to log the exact machine, and the time of the generation. We think that one attack against our solution might be hacking our computers those generated these keys and then influence generation. Therefore, we thought it is more important to save exact generation time and to show that it was before the service was get to the public in contrast to having common software generating those parameters.
Are You sure that these keys are not compromised?
No! We have no proofs and we don’t know surely if our infrastructure was never compromised. We don’t know if our hardware has any backdoor or weaknesses, and the same stands for the tool, openssl, which we used for parameter generation. It is only our best wish, that we made something usable and do not harm security of anyone.
How to contact you?
Contact us through dhpdb @.. ukatemi.com.
