blog: make your uncrackable keygen with RSA

[nikos]

yes, I saw it too, this shouldn't have happened according to theory

I'm a sad panda

512 bits encryption should be strong enough for hackers, so I am investigating for backdoors

[snemarch]

yes, I saw it too, this shouldn't have happened according to theory

I'm a sad panda

Don't worry - you're likely still doing enough to keep the honest people honest, and the people who are doing crack (:P) don't mind a patch+keygen combination. But of course it can feel as an attack on personal pride. Don't worry too much about that, though - even big people like Microsoft have failed (using bad parameters for their elliptic curvo crypto used for windows cd-keys meant that was first partially and later fully broken... but then it turned out MS did, after all, have a full database of volume license keys, and could block invalid serials from windows update after all ).

512 bits encryption should be strong enough for hackers, so I am investigating for backdoors

Not really - some cracking teams have had distributed setups for years, and today it's very easy to rent a lot of computing power relatively cheap from services like Amazon EC3. And a lot of the guys in the scene aren't kids anymore (even if some behave that way), but people with well-paid jobs who are doing it for the intellectual challenge (and/or childish bragging rights).

Apart from just the availability of raw bruteforcing power, there's various attacks on RSA if you've been unlucky to select weak parameters - see for instance this. And as mentioned earlier, ASProtect was fully keygenned (was only RSA1024, though, but it was back in 2001).

[nikos]

see my PM

[yam001]

Rightly said now with the CPU power available, using 512 RSA bit encryption would be calling for trouble itself . As the user don't have to type the key manually you should have used 1024 or more bits...

[pcunite]

Nikos,
Thank you for all your posts on software subjects. I am looking into implmenting Brandon Staggs Partial Serial Number Verification or what you've suggested ... all I'm interested in is stopping keygens, nothing else. Is it still working okay for you?

[nikos]

my version has been keygenned so i can't say it is working as intended
i am still trying to figure out if the RSA was broken or my webserver

[snemarch]

my version has been keygenned so i can't say it is working as intended
i am still trying to figure out if the RSA was broken or my webserver

My bet is still on the RSA being broken.

You really do want a keysize of at least 2048 bits, and you want to be sure the rsa-keygen discards weak keys (and has a strong PRNG, which isn't seeded by something reasonable - definitely NOT current time ).

[00x3]

Hi,

Niko have quite good idea. But if your app run then app should be bypass. Even Niko latest version also patched. And people believe crack/patch can be danger for PC but not for popular releaser. Also I don’t believe Armadillo or Themida or Winlicense.

And recently I buy Enigma Protector and seems very strong update and support.

And also I read a such topic (can not remember the link) where Enigma team works on that. 0-1% false positive alarm. I will give that link Monday.

And my regards to Niko as a talented man.

[bailey]

Thanks for the excellent blog article. I was wondering if you ever figured out the weakness of this system, and how the keygen was made?

Would it maybe be better to somehow encrypt the license info (1.001|KT.1|1|26.06.2010|0|Joe Bloggs|some@email.com), so the resultant key you send to the user doesn't have this in plaintext? The software program could use the public key to decrypt, and get this info. By leaving the license info in plain text that seems to give the attacker a little more control, like maybe they could put an empty string in here.

There is some discussion of this method here:

http://stackoverflow.com/questions/3002 ... -generated

and it is mentioned a couple of times to "encrypt with a private key", as opposed to "sign with the private key". I wonder if this isn't more robust...

[nikos]

most probably 512 bits is not strong enough for today's number crunching machines. The 1024 bit ultimate version on the other hand has no keygen
www.zabkat.com/blog/keygen-safety-part-2.htm

[Tuxman]

I doubt there's a thing like "secure keygens". After your blog post had been released, OpenSSL was proven to be an insecure pile of wrappers for not working algorithms. Welcome to open source.

[nikos]

well there is still no keygen for the ultimate version so the horsemen of apocalypse are still at bay
if openssl was that bad then all internet commerce and https would be down the drain

[Tuxman]

My server runs LibreSSL, so do a couple of others. Google has its own SSL implementation too, so I doubt OpenSSL "drives the web". It's the poor man's version.

Maybe people don't care about the extra functions the Ultimate version provides them?

[snemarch]

I doubt there's a thing like "secure keygens". After your blog post had been released, OpenSSL was proven to be an insecure pile of wrappers for not working algorithms. Welcome to open source.

Tuxman, OpenSSL is a stinking pile of crap, but it seems you don't really understand how it's a dungpile.

All the standardal gorithms work fine, it's mainly the protocol code that has had (serious) problems - but that obviously doesn't affect algorithm security. The instance of bad key generation was because some Debian developer decided to rip out code he didn't understand, and thus reducing entropy to useless levels. Similar to how one famous exe-protector had it's private 1024-bit key factorized - the author used a very bad (time/date-based) seed for his PRNG.

As for running LibReSSL... it's a very good initiative, but I certainly don't hope you're running it in production yet - especially not if you're running it on anything but OpenBSD. And OpenSSL indeed does "drive the web" - it has a very large deployment base because it's the default go-to SSL library, and it's not like the alternatives are that much better - GnuTLS and Apples SSL implementation have also had very embarrassing bugs, and Android has had some oops-wtf related to certificate chain validation. Oh, and apart from the "whatever" customer-facing webshop sites, there's also a lot of critical infrastructure depending on OpenSSL.

Nikos, 1024bit is probably a bit much to factor if there aren't weaknesses like a weak PRNG seed. I'm a bit surprised nobody has done the obvious patch-public-key + keygen combo, though... perhaps because the Ultimate extras are a bit too lacklustre compared to the effort?

[ckit]

No keygens but crack for older yes...
http://isohunt.to/torrent_details/64197 ... -TorDigger

So the newer 2.5.x branch for Ultimate seems to be bulletproof for now...
but Pro seems to be broken!
http://isohunt.to/torrent_details/11756 ... -TorDigger