Still, you could cut down the character count using base64 instead of hexadecimal characters, it would go from 40 characters to 27. Generally it's not a good idea to truncate hashes, they are designed to exploit all the length of the output to provide good security and resistance to collisions. Would I obtain sufficient results if I took the 40 char result and, say, truncated all but the last 16 characters?

However, what I am seeing from sample output of SHA-1 keys is that they are pretty long (40 chars). The device compares the given hash to the hash generated for each feature, and if it finds a match it enables the feature.īy the way, to keep the character count down I'd suggest to use base64 as encoding after the hashing pass. You could just concatenate the serial number of the device, the feature name/code and some secret salt and hash the result with SHA1 (or another secure hashing algorithm). Would I obtain sufficient results if I took the 40 char key and, say, truncated all but the last 16 characters?

I need a simple algorithm that can take sequential numbers and generate unique, non-sequential keys of 16-20 alphanumeric characters. Seeds for the keys can be derived from the hardware serial number, which is available in both locations. Therefore, an algorithm must be implemented in such a way that these keys can be generated from both the server and from within the device. Our hardware is not connected to the internet. Next, we email them a product key which they input into their hardware to unlock the feature. The user calls us up, they request the feature and sends us a payment. The desired implementation steps are simple. We are wanting to implement a new feature for our devices that our users can unlock when they purchase an associated license key.

I'm working on a project that involves writing low-level C software for a hardware implementation.

Serials unlock the world