Keeping with ibm-main tradition, I'll steer this into a different ditch :-)
"Seriously, stop using RSA" This is a very interesting writeup/presentation, I've shorted the URL for obvious reasons https://tinyurl.com/yxw5xvmv IMO, ECDSA (NIST curves) are much better than RSA, although researchers seem to prefer Curve25519 since the curve wasn't chosen by a government. On Tue, Aug 27, 2019 at 7:56 AM Chad Rikansrud < mainfr...@bigendiansmalls.com> wrote: > " Non-repudiation for the message is not guaranteed by a hash. There is > more than 1 message that could match that hash. " > > The breadth of privacy on the internet as we know it depends upon being > able to trust that a hashing algo + cryptographic signature verifies the > non-repudiation of the sender. > > Couple other items on this thread: > > it's true are an infinite number of inputs that would generate any given > hash, and random inputs can and have created general hash collisions (md5 > for instance has known random input that creates identical hashes), > however, creating a meaningful input that (say in this case would be > similar to what someone would want to say & sign, but slightly different so > as to alter the message) - is cryptographically infeasible with today's > compute power / hashes. Great article explaining collisions etc ( > https://www.sciencedirect.com/topics/computer-science/hash-collision) > > For RSA public key systems - there is only 1 private key for any given > public key. The keypairs certainly can and have been reused - that all > depends on how good your entropy in choosing random numbers is (see > https://www.nytimes.com/2012/02/15/technology/researchers-find-flaw-in-an-online-encryption-method.html > ) > > There's no requirement outside of p & q being prime (In RSA) , that the > public exponent or its related private exponent need not be prime, only > co-prime (having no factors in common) - as was mentioned earlier. That > said, one of the most common public exponent is prime (65537) > > All in all, to the original point though, sharing the private key by that > vendor was terrible - you could effectively impersonate them in any / all > situations that used that keypair/cert if you had a privileged position or > means. Yikes. > > Chad > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
