該
我的問題是如何通過 128 位橢圓曲線創建產品密鑰，因為如果您加密 X 長度的文本，您會得到比 X 長得多的加密？
下面是我寫的測驗代碼，8個字符的訊息加密成28個位元組的陣列，我有什么問題，或者根本不可能使用橢圓曲線創建一個25個字符的產品密鑰？
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));
}
}
uj5u.com熱心網友回復：
“如果你加密 X 長度的文本，你會得到比 X 長得多的加密”，這不是真的，而是加密以塊的形式進行。
128位EC加密的基本操作是加密一個128位的明文塊，產生一個128位的密文塊——大小完全相同。
如果您想加密較小的內容，則需要將其四舍五入到整數個塊，這就是為什么您的非常短的訊息會變得更長的原因。
還有一堆額外的東西經常被添加到訊息中：
- 像 CBC 這樣的加密模式在開始時需要一個隨機資料塊。
- 通常會添加訊息驗證碼 (HMAC) 以防止篡改。
- 添加填充以將訊息擴展到整個塊數，這必須包括額外資訊以指示原始訊息大小。如果您的訊息正好是一個塊長，那么這個帶有額外資訊的填充將消耗一個額外的塊。
對于您的應用程式，您不需要任何這些額外的東西。你從 MD5 得到 128 位，你應該只加密 128 位明文位塊來生成 128 位密文位塊。
我不確定您如何以正確的方式構建您的 bouncycastle IesEngine 實體之一。但就分組密碼的常用引數而言：
- 通常你必須指定一個模式。歐洲央行是正確的選擇。它代表“電子密碼本”，因為語言很古老，意思是“只是加密塊”。
- 通常您必須指定要使用的填充型別。您應該指定 NO PADDING。
- 通常你必須配置使用什么樣的驗證碼。您似乎已指定 HMAC。正確的值是 NO AUTHENTICATION CODE。
如果設定正確，則可以加密 16 位元組（128 位）訊息以生成 16 位元組輸出。
uj5u.com熱心網友回復：
與其說“加密”，不如說正確的方法是使用簽名。
在某些輸入上使用散列函式，客戶端和服務器都可以計算而無需傳輸任何內容。然后服務器可以對該哈希進行簽名，客戶端可以驗證該簽名。
128 位 ECC 簽名在這里很有用，因為它們只有 128 位長。因此，將整個值編碼為用戶可以鍵入的文本字串是合理的。另外，如果不知道密鑰，攻擊者應該“不可能”（或者至少在不使海洋沸騰的情況下……）生成假密鑰。
然而，在始終在線互聯網連接的時代，您想像這樣惹惱您的潛在客戶嗎？他們必須在您的在線訂單頁面中輸入與產品激活螢屏完全相同的輸入。使用和支持可能會相當令人沮喪。
另外，沒有機制可以防止使用相同的密鑰進行多次安裝。因此，任何軟體盜版者要么破解軟體以洗掉您的激活頁面，要么購買一個產品密鑰并分發它。
恕我直言，任何簡單的混淆都應該足以作為產品密鑰。由于任何具有破壞它的技能的攻擊者都可能無論如何都會將其洗掉。為了提高安全性，您應該執行一些在線檢查。或者只是相信您的合法用戶會做正確的事情。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/407318.html
標籤：