Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

By all means. Ed25519 (which underlies signify) is a pretty decent modern signature scheme. (tweetnacl.c also implements it, in less code.)

It also seems you want to expire things, so I do feel I have to warn you that signatures are a totally separate thing to a secure time source, which is a whole different bag of marbles.

However, since what you're designing sounds like a logic bomb/copy protection/DRM system, I must say what I've been saying for the last quarter-century or so: please do not design your software to deliberately fail. That is a bad call: trust me on this one. Any crypto that you do to support it, even if the crypto itself is sound, is just tapdancing around a failure state.



So, use case would be something like:

Software is shareware, gets a little naggy within 30 days of license expiration, send money to get a new license file, which makes the nagging go away. No cessation of service.

I'm not worried about clock spoofing--I assume basically good-faith customers.

Signing would help people from just copy-pasting certificates around. If they want to go into the executable and rewrite the routines, well, there's only so much one can do, yes?


If you assume basically good-faith users: why nag them? After they registered? Aren't they assuming basically good-faith authors? Why do you think people who you'd nag after they registered would copy-paste keys but not download a crack?

(Your registrations are time-limited? That's very unusual for self-described "shareware". That's pretty much "commercial, but your demo nags".)

You're welcome to choose whatever business model works for you, of course, but take it from me, this one's straight from the early '90s. I hope it works for your users too.


It's a non-trivial task to design software that will deliberately fail and cannot be easily by-passed with a debugger.


A massive understatement, for any software that is itself non-trivial.

And unfortunately, the harder someone tries to reach that goal, the more fragile their software becomes. A lose/lose situation.

It really is better to engineer software to work, not to fail.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: