理解JWK与EC公钥坐标编码
json web key (jwk) 是一种标准化的方式，用于表示加密密钥。对于椭圆曲线（ec）密钥，公钥通常由曲线类型、x坐标和y坐标组成。jwk规范（rfc 7518）明确指出，ec公钥的x和y成员应包含椭圆曲线点的x和y坐标，它们以大端字节序表示，并经过base64url编码。这意味着，在从私钥推导出公钥点后，我们需要将这些坐标转换为特定长度的大端字节序列，然后进行base64url编码。
在实际开发中，尤其是在使用第三方库如elliptic.js从EC私钥推导公钥时，开发者可能会遇到生成的x和y坐标与通过Web Crypto API导出的JWK不匹配的问题。这通常是由于对JWK规范中坐标处理细节的理解不足所致。
问题分析：推导公钥坐标不匹配的原因
当尝试从一个EC私钥（d）推导出对应的公钥点，并将其x和y坐标转换为JWK格式时，可能出现不匹配。以下面的JavaScript代码为例，它尝试使用elliptic.js库从P-521曲线的私钥生成公钥，并与Web Crypto API导出的JWK进行比较：
const elliptic = require('elliptic');
const EC = elliptic.ec;
const {base16, base64url} = require('rfc4648');
const BN = require("bn.js");
// 辅助函数：将十六进制字符串填充为偶数长度，以确保字节转换正确
const padBase16ToWholeOctets = s => s.length % 2 === 0 ? s : '0' + s;
// 辅助函数：将BN对象转换为Base64url编码的字符串
const bnToB64 = n => base64url.stringify(base16.parse(padBase16ToWholeOctets(n.toString(16))));
console.log('begin');
(async () => {
// 使用Web Crypto API生成P-521密钥对
let keyPair = await crypto.subtle.generateKey({ name: "ECDSA", namedCurve: "P-521" }, true, ['sign']);
let jwk = await crypto.subtle.exportKey("jwk", keyPair.privateKey);
console.log('Web Crypto API导出的JWK:', jwk);
// 从JWK中提取私钥d，并转换为十六进制
const dHex = base16.stringify(base64url.parse(jwk.d, { loose: true }));
// 使用elliptic.js库进行计算
const ec = new EC('p521');
// 错误示范：直接使用toJSON()获取x和y坐标
const [x, y] = ec.curve.g.mul(new BN(dHex, 16, 'be')).toJSON();
console.log(`期望的x (Web Crypto): ` + jwk.x);
console.log(`实际计算的x (elliptic.js - toJSON): ` + bnToB64(x)); // 结果不匹配
console.log(`期望的y (Web Crypto): ` + jwk.y);
console.log(`实际计算的y (elliptic.js - toJSON): ` + bnToB64(y)); // 结果不匹配
})();上述代码中，elliptic.js计算出的x和y与jwk.x和jwk.y不一致。这主要是由两个关键问题导致的：
- 坐标未规范化： elliptic.js库中，直接使用toJSON()方法获取的x和y坐标可能未经过规范化处理。这意味着它们可能不是最低有效位表示，或者在表示上存在差异。
- 字节填充不完整： JWK规范要求x和y坐标必须表示为固定长度的大端字节序列。例如，对于P-521曲线，其坐标长度为66字节。如果计算出的坐标值在转换为十六进制后再转换为字节时，没有填充到所需的固定长度（即在前面补零），则Base64url编码的结果将不正确。
解决方案与正确实践
要正确地从私钥推导JWK EC公钥坐标，并确保其符合规范，需要解决上述两个问题。
1. 获取规范化的坐标值
elliptic.js库提供了专门的方法来获取规范化的坐标值：point.getX()和point.getY()。这些方法确保返回的BN（BigNumber）对象代表了椭圆曲线点的标准x和y坐标。
将原始代码中的：
const [x, y] = ec.curve.g.mul(new BN(dHex, 16, 'be')).toJSON();
替换为：
const point = ec.curve.g.mul(new BN(dHex, 16, 'be')); const x = point.getX(); const y = point.getY();
这样可以确保我们得到的是经过库内部规范化处理的坐标值。
2. 确保正确的字节填充
JWK规范要求坐标字节序列必须是固定长度的。对于P-521曲线，其坐标长度为66字节。这意味着其十六进制字符串表示应该有132个字符（每个字节两个十六进制字符）。如果坐标值小于此长度，则需要在其前面填充零。
修改bnToB64辅助函数，增加填充逻辑：
// 修改后的辅助函数：确保十六进制字符串填充到指定长度
const bnToB64 = (n, expectedHexLength) => {
const hexString = padBase16ToWholeOctets(n.toString(16));
// 使用padStart确保十六进制字符串达到预期长度，不足则在前面补零
const paddedHexString = hexString.padStart(expectedHexLength, '0');
return base64url.stringify(base16.parse(paddedHexString));
};在使用此函数时，需要传入正确的expectedHexLength。对于P-521曲线，坐标长度为66字节，因此expectedHexLength应为66 * 2 = 132。
整合后的示例代码
以下是整合了上述修正的完整代码示例：
const elliptic = require('elliptic');
const EC = elliptic.ec;
const {base16, base64url} = require('rfc4648');
const BN = require("bn.js");
// 辅助函数：将十六进制字符串填充为偶数长度，以确保字节转换正确
const padBase16ToWholeOctets = s => s.length % 2 === 0 ? s : '0' + s;
// 修正后的辅助函数：将BN对象转换为Base64url编码的字符串，并进行长度填充
const bnToB64 = (n, expectedHexLength) => {
const hexString = padBase16ToWholeOctets(n.toString(16));
const paddedHexString = hexString.padStart(expectedHexLength, '0');
return base64url.stringify(base16.parse(paddedHexString));
};
console.log('开始执行...');
(async () => {
// 使用Web Crypto API生成P-521密钥对
let keyPair = await crypto.subtle.generateKey({ name: "ECDSA", namedCurve: "P-521" }, true, ['sign']);
let jwk = await crypto.subtle.exportKey("jwk", keyPair.privateKey);
console.log('--- Web Crypto API导出的JWK ---');
console.log(jwk);
// 从JWK中提取私钥d，并转换为十六进制
const dHex = base16.stringify(base64url.parse(jwk.d, { loose: true }));
// 初始化elliptic.js的P-521曲线
const ec = new EC('p521');
// 从私钥d计算公钥点
const point = ec.curve.g.mul(new BN(dHex, 16, 'be'));
// 获取规范化的x和y坐标
const xBN = point.getX();
const yBN = point.getY();
// P-521曲线的坐标长度为66字节，对应132个十六进制字符
const P521_COORD_HEX_LENGTH = 132;
console.log('\n--- 比较计算结果 ---');
console.log(`期望的x (Web Crypto): ` + jwk.x);
console.log(`实际计算的x (elliptic.js): ` + bnToB64(xBN, P521_COORD_HEX_LENGTH));
console.log(`期望的y (Web Crypto): ` + jwk.y);
console.log(`实际计算的y (elliptic.js): ` + bnToB64(yBN, P521_COORD_HEX_LENGTH));
// 验证结果是否匹配
if (jwk.x === bnToB64(xBN, P521_COORD_HEX_LENGTH) && jwk.y === bnToB64(yBN, P521_COORD_HEX_LENGTH)) {
console.log('\n✅ 恭喜！计算出的x和y坐标与Web Crypto API导出的JWK完全匹配。');
} else {
console.log('\n❌ 错误：计算出的x或y坐标与Web Crypto API导出的JWK不匹配。');
}
})();运行上述修正后的代码，您会发现elliptic.js计算出的x和y坐标现在与Web Crypto API导出的JWK完全匹配。
注意事项与总结
- 曲线特定的长度： 不同椭圆曲线（如P-256、P-384、P-521）的坐标字节长度是不同的。例如，P-256曲线的坐标长度为32字节（十六进制为64字符），P-384为48字节（十六进制为96字符），P-521为66字节（十六进制为132字符）。在实现中，务必根据所使用的曲线类型，设置正确的expectedHexLength。
- JWK规范的严格性： JWK规范在密钥表示上非常严格，即使是微小的细节（如字节填充）也可能导致不兼容或验证失败。在处理加密密钥时，严格遵循规范是确保互操作性和安全性的关键。
- Web Crypto API作为参考： Web Crypto API通常被认为是加密操作的权威实现。当您在自定义实现中遇到问题时，可以将其输出作为黄金标准进行比较和验证。
- 细节决定成败： 在加密领域，对细节的关注至关重要。本文所讨论的坐标规范化和字节填充问题，虽然看似细微，却是确保JWK EC公钥正确性的关键环节。
通过理解和应用这些规范化的处理方法，开发者可以自信地从私钥推导出符合JWK规范的EC公钥坐标，确保其在各种系统和应用中的兼容性。
