{"id":22452649,"url":"https://github.com/totaltechgeek/nspdh","last_synced_at":"2025-03-27T12:42:32.367Z","repository":{"id":148358987,"uuid":"95147976","full_name":"TotalTechGeek/nspdh","owner":"TotalTechGeek","description":"Utility for generating secure Diffie-Hellman Parameters (and more) 100x-10000x more quickly.","archived":false,"fork":false,"pushed_at":"2018-10-02T17:42:41.000Z","size":81,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":3,"default_branch":"master","last_synced_at":"2025-02-01T17:13:47.535Z","etag":null,"topics":["diffie-hellman","dsa","encryption","fast"],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-2-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/TotalTechGeek.png","metadata":{"files":{"readme":"readme.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-06-22T19:08:08.000Z","updated_at":"2018-10-02T17:42:43.000Z","dependencies_parsed_at":"2023-05-13T05:00:10.959Z","dependency_job_id":null,"html_url":"https://github.com/TotalTechGeek/nspdh","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/TotalTechGeek%2Fnspdh","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/TotalTechGeek%2Fnspdh/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/TotalTechGeek%2Fnspdh/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/TotalTechGeek%2Fnspdh/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/TotalTechGeek","download_url":"https://codeload.github.com/TotalTechGeek/nspdh/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":245850213,"owners_count":20682635,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["diffie-hellman","dsa","encryption","fast"],"created_at":"2024-12-06T06:11:59.544Z","updated_at":"2025-03-27T12:42:32.346Z","avatar_url":"https://github.com/TotalTechGeek.png","language":"C++","funding_links":[],"categories":[],"sub_categories":[],"readme":"# nspdh \n\n### So, what is it?\nnspdh generates secure parameters for Discrete Log Cryptography, like the Diffie-Hellman key exchange and the Digital Signature Algorithm, and does it much (potentially hundreds to thousands of times) faster than our top standard algorithms. \n\n## Faster?\n\nIt's reasonably fast, and I think with speed improvements like this Discrete Log Cryptography might finally be seen as a viable alternative to RSA again. The speed boost over the standard algorithms increases with the bit size requested.\n\nOn a 2.4GHz i3-3110M Processor (from 2012), it was able to generate 2048 bit parameters at an average of 4 seconds.\nOpenSSL consistently lagged behind, with each sample taking closer to two minutes. \n\nAt 3072 bits, nspdh was able to generate new parameters nearly every 7.7 seconds.\nOpenSSL took nearly four minutes.\n\nAt 4096 bits, nspdh was able to generate new parameters nearly every 14 seconds.\n\nAt 8192 bits, nspdh was able to generate parameters consistently in the range of 2-3 minutes.\nI left OpenSSL running for nearly 5 days before I had to terminate the process. \n\n16384 bit parameters can be found in 6-18 minutes. \n\n## What's being done differently? \n\nWell... it goes against the current standard practices *(for Diffie-Hellman Parameters)*... but with good reason! \n\n**Don't worry: I didn't make the amateur mistake of just selecting a random prime.**\n\nAfter researching Discrete Log Cryptography and contacting a few people who have written on the topic, I disagreed with a few \"design\" and measurement decisions earlier cryptographers made a few decades ago. \n\nThe Discrete Logarithm problem has quite a few attack algorithms, while most of the well known attacks focus mostly on the modulus, there are attacks that rely solely upon the largest prime factor of the modulus - 1. The specific algorithm is called the [Pohlig-Hellman algorithm](https://en.wikipedia.org/wiki/Pohlig%E2%80%93Hellman_algorithm).\n\nSince at the time the general consensus was that you should measure the strength of a cyclic group by the size of the modulus, cryptographers made the decision to attempt to \"maximize\" the strength of the cyclic group against this attack for any given modulus. This led to them using \"Safe-Primes\", which exist in the form 2p+1, where p is a prime. \n\nThis effectively guarantees that the largest prime factor will be at a minimal distance from the modulus, \"maximizing\" the cyclic group's strength.  \n\nThe problem is that the problem was being observed **backwards**. This decision was decent when Diffie-Hellman moduli were 256 and 384 bits, when a slightly larger gap could dramatically impact the security. However, safe primes are also far more dense in those ranges. Safe primes are quite sparse at larger sizes, so it might be time to consider another approach.\n\nThe size of the largest factor of the modulus-1 is the lower bound of the cyclic group's security, since it will always be smaller than the modulus prime itself. The standard ideology currently uses a bit of a top-down approach, that generates a modulus with a minimal distance from the factor. \n\nThis approach is backwards, and once you reverse your thinking, an alternative approach becomes obvious. \n\n## Bottom-Up Discrete Log Parameter Generation.\n\nBecause the terminology doesn't seem to exist, I will propose some to make this description simpler.\n\nI will be calling the largest prime factor of the modulus - 1 the \"Pohlig-Hellman prime\", its log size the \"Pohlig-Hellman strength\", and the modulus log size \"modulus strength\".\n\nThe method is this: \n- Generate a Pohlig-Hellman Prime at the requested strength.\n- Find a corresponding prime modulus within a bounded range. \n\nThe prime modulus will exist in the form 2np + 1, where n is a random integer within a bounded range. This range is bounded to make the parameters easy to verify against backdoors (since you can easily find the pohlig value from the modulus). This is called a \"nearly safe prime\", but is no less secure than a \"safe prime\".\n\nn by default is 4096, but 65536 is still acceptable (it's actually easy to verify all n values up to 2^32, but I don't recommend going above 2^24).  \n\nPrimes within this form are far less sparse (technically all primes greater than 3 exist in this form), and are far easier to find. While this creates a Discrete Log Group with a slightly larger gap between the PH Prime and the Modulus, this will have **zero** impact on its cryptographic strength. No known algorithm can exploit the gap between the primes (otherwise DSA would be broken). \n\nAs an example, a cyclic group with a 2048 Bit Pohlig-Hellman Strength might have a 2056 Bit Modulus Strength. (2048, 2056) is provably better than the (2047, 2048) combination, against all known algorithms. \n\nIn the time it used to take to generate 2048 bit parameters, you could generate far more secure 5120 bit parameters.\n\n---\n\n**Let me to be clear:** This is not a *completely* new approach, or necessarily a new mathematical realization. The NIST already acknowledges this is secure in [their DSA specifications](https://csrc.nist.gov/csrc/media/publications/fips/186/3/archive/2009-06-25/documents/fips_186-3.pdf) in the choice of their (L, N) pairs. I'm just recommending a different scheme that'll accelerate parameter generation and still allow verification against backdoors (without extra file overhead).\n  \nI do, however, have some concerns with the current DSA specifications. If the initial steps of the Pohlig-Hellman algorithm could be computed on a quantum computer, and the DSA cyclic group was \"backdoored\" (intentionally constructed in such a way that the greatest factor will be N), then a Quantum computer of size N might be able to break the cyclic group quickly (rather than size L).  \n\n## How do I actually use the software?\n\nAt the moment, I want to focus on publishing a math paper to prove the security of Nearly Safe Primes to skeptics, so I haven't fleshed out the documentation yet.\n\nUntil then, try running it with:\n```\nnspdh -h\n```\n\n## To Build \n### Building with dave \n\nTo build the software, run \n\n``` \njava -jar Dave.jar \n```\n\nWhich will run the init script and fetch all necessary dependencies (Crypto++, ASN1C) and will patch the files to be built for your OS. Building with dave will allow you to support OpenSSL files. \n\nJava 8 or higher is required. Tested with g++, clang, Mingw32_64, and Visual Studio 2017.\n\n**WARNING**: If you are compiling this project for Windows, we recommend you use something like 'cmder' as your shell (as it adds a few Unix utilities Dave takes advantage of). Otherwise, please install 7-Zip and add it to your path. \n\n**WARNING**: If you are compiling this project for the Mac, the default clang compiler will not work, as it lacks OpenMP support. If you wish to compile this project, you may have to tell the build to use a different compiler using something along the lines of: \n```\nexport CXX=g++-7\nexport CCX=gcc-7\n```\nPrior to running dave.  \n\n### Building without dave\n\nIf you do not want to build with dave, or you would prefer to build the software with a different compiler, you will need to download and extract Crypto++, build it, and include it in the final build. The software also requires the OpenMP flag to be enabled for your compiler. \n\nThis build will not include the OpenSSL compatibility features.\n\nFor example, for the Visual Studio compiler you will basically do something along the lines of\n```\ncl src/*.cpp /openmp /Ox cryptlib.lib /DForce2011\n```\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftotaltechgeek%2Fnspdh","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftotaltechgeek%2Fnspdh","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftotaltechgeek%2Fnspdh/lists"}