Elliptic Curve implementation for product keys

Question

Here I read about the basic idea of how to use asymmetric Elliptic Curve encryption to create a product key, here is a quote:

My question is how is it possible to create a product key by a 128-bit Elliptic Curve, since if you encrypt X-length text you get encryption that is much longer than X?

Below is the test code I wrote, an 8-character message encrypted to an array of 28 bytes, what am I wrong with, or is it not at all possible to use the Elliptic Curve to create a 25-character product key?

using Org.BouncyCastle.Crypto.Generators;
using Org.BouncyCastle.Crypto.Parameters;
using Org.BouncyCastle.Security;
using System.Text;
using System.Linq;
using Org.BouncyCastle.Crypto.Engines;
using System.Diagnostics;
using Org.BouncyCastle.Crypto.Agreement;
using Org.BouncyCastle.Asn1.X9;
using Org.BouncyCastle.Crypto.Digests;
using Org.BouncyCastle.Crypto.Macs;

class Program
{
    public static void Main(string[] args)
    {
        var keyPairGenerator = new ECKeyPairGenerator("ECDH");
        var x9 = ECNamedCurveTable.GetByName("secp128r1");
        keyPairGenerator.Init(new ECKeyGenerationParameters(new ECDomainParameters(x9), new SecureRandom()));
        var keyPair = keyPairGenerator.GenerateKeyPair();

        byte[] d = new byte[] { 1, 2, 3, 4, 5, 6, 7, 8 };
        byte[] e = new byte[] { 8, 7, 6, 5, 4, 3, 2, 1 };
        var p = new IesWithCipherParameters(d, e, 64, 128);

        var cipher = new IesEngine(
                       new ECDHBasicAgreement(),
                       new Kdf2BytesGenerator(new Sha1Digest()),
                       new HMac(new Sha1Digest()));

        var message = Encoding.UTF8.GetBytes("12345678");

        cipher.Init(true, keyPair.Private, keyPair.Public, p);
        var encryption = cipher.ProcessBlock(message, 0, message.Length); // encryption length is 28 <==

        cipher.Init(false, keyPair.Private, keyPair.Public, p);
        var decryption = cipher.ProcessBlock(encryption, 0, encryption.Length);

        Debug.Assert(decryption.SequenceEqual(message));
    }
}

Answer 1

It is not true that "if you encrypt X-length text you get encryption that is much longer than X", but the encryption proceeds in blocks.

The basic operation of 128-bit EC encryption is to encrypt a 128-bit plaintext block to produce a 128-bit ciphertext block -- exactly the same size.

If you want to encrypt something smaller, it needs to be rounded up to a whole number of blocks, which is why your very short message got a lot longer.

There is also a bunch of extra stuff that is often added to the message:

• Encryption modes like CBC require a block of random data at the start.
• A message authentication code (HMAC) is often added for tamper prevention.
• Padding is added to expand the message out to a whole number of blocks, and this must include extra information to indicate the original message size. If your message is exactly one block long, this padding with extra information will consume a whole additional block.

For your application, you don't need any of this extra stuff. You get 128 bits from MD5, and you should encrypt exactly and only that block of 128 plaintext bits to produce a block of 128 ciphertext bits.

I'm not sure how you construct one of your bouncycastle IesEngine instances the right way. But in terms of the usual parameters for block ciphers:

• Usually you have to specify a mode. ECB is the correct choice. It stands for "electronic code book", because the language is ancient, and means "just encrypt the blocks".
• Usually you have to specify the type of padding to use. You should specify NO PADDING.
• Usually you have to configure what kind of authentication code to use. You seem to have specified HMAC. The correct value is NO AUTHENTICATION CODE.

If you set it up right, then you can encrypt a 16-byte (128-bit) message to produce a 16-byte output.

Answer 2

Rather than saying "encryption", the right way to do this is by using a signature.

Use a hash function on some input, which both the client and server can calculate without needing to transmit anything. Then the server can sign that hash, and the client can verify the signature.

128-bit ECC signatures are useful here, because they are only 128-bits long. So it's plausible to encode the entire value as a text string that the user can type. Plus without knowledge of the secret key, it should be "impossible" (or at least without boiling the oceans...) for an attacker to generate fake keys.

However in the age of always online internet connections, do you want to annoy your potential customers like this? They have to type in exactly the same input into your online order page as the product activation screen. Which can be rather frustrating to use and support.

Plus there's no mechanism to prevent multiple installations using the same key. So any software pirate will either crack the software to remove your activation page, or buy one product key and distribute it.

IMHO any simple obfuscation should be sufficient as a product key. Since any attacker with the skills to break it will probably remove it anyway. For more security you should be performing some online check. Or just trust your legitimate users to do the right thing.