如何使用BouncyCastle从java/kotlin中的文件/字符串读取RSA公钥

我正在尝试解析kotlin中RSA格式的公钥。我有一个字符串中的键，其内容如下：

-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAwAzOKC8d0o0dcv1KqILLehASGgOWyjlAc+adazix6ThhX7QeD3Qw
HzxPpbwsJrVPIEMEIN383awIqnCfIL+AbCQPL13XaUCCS74wC5a84X1r6hcI5XO1
9CPAn+jBKmTr4hPaHWKxuhfO3PcXxGfQdXyqNT96bCYnAYaeSECohFjqDbe+RFcL
1lIns2GtQPMh1/uDyhPA+8HSguREWn+Ac3I2c0wtrzZa6R4nruPgIi6XbWRqAskr
tzbO2Xy6O1DcERH9tg+es/pbrWHRHrwEmLXorj3iGqkJJBUmLeW6B5EjmIgiukdJ
dw7bLTNcwf2n0BLJy/bgnhcw4TMOzUadSQIDAQAB
-----END RSA PUBLIC KEY-----

我找到了很多代码示例来实现这一点，其中包括使用String.replace（）修剪开始和结束，但这对我来说似乎很难。它包括为遇到的不同类型的“文件”创建解析器的能力。我正在尝试这个：

try {
    val parser = PEMParser(StringReader(publicKeyString))
    val pemObject = parser.readPemObject()
    val pemContent = pemObject.content
    val key = org.bouncycastle.asn1.pkcs.RSAPublicKey.getInstance(pemContent)
    serviceLogger.info("Key object: {}", key)
} catch (e: Exception) {
    serviceLogger.error("Could not generate key from keyspec", e)
}

我得到的内容（字节数组）没有问题，但当我尝试将其解析为RSAPublicKey时，我得到了以下结果：

java.lang.IllegalArgumentException: failed to construct sequence from byte[]: DEF length 3 object truncated by 2

我搞不清楚的是，我是否使用整个PemObject的内容正确调用了RSAPublicKey.getInstance（），或者这个异常告诉我我的密钥有问题

我在这方面找到的示例非常古老，API似乎已经发展到我不必手动切碎字符串的地步

我怀疑这是否真的有帮助，但我正在使用rsa密钥对生成此文件：

func PublicKeyToPemBytes(prvkey *rsa.PrivateKey) ([]byte, error) {
    var pubkey *rsa.PublicKey
    pubkey = &prvkey.PublicKey

    pubkey_bytes := x509.MarshalPKCS1PublicKey(pubkey)
    if pubkey_bytes == nil {
        return nil, errors.New("Public key could not be serialized")
    }

    pubkey_pem := pem.EncodeToMemory(
        &pem.Block{
            Type:  "RSA PUBLIC KEY",
            Bytes: pubkey_bytes,
        },
    )

    return pubkey_pem, nil
}

---

go rsa.PublicKey对象包含一个N和一个E。它给我一个如上所列的文件，base64解码的结果是完全相同的长度，270字节。

dave_thompson_085是正确的。这段代码确实有效。他问我是否修改了数据，这让我更仔细地查看了数据，我意识到我在base64上做的是一个.toUpperCase（）。结果仍然是完全有效的base64，有些位在这里和那里翻转。我本不该那样做的。toUpperCase（）我只是在他说那句话之前没看到而已。蹦蹦跳跳确实有效。

戴夫·汤普森085是对的。这段代码确实有效。他问我是否修改了数据，这让我更仔细地查看了数据，我意识到我在base64上做的是一个.toUpperCase（）。结果仍然是完全有效的base64，有些位在这里和那里翻转。我本不该那样做的。toUpperCase（）我只是在他说那句话之前没看到而已。Bouncy确实有效。

您是否更改了数据并将其截断？它的一部分可能在一个有效的PKCS1公钥中，而不仅仅是偶然发生的，但是其他部分是完全错误的。这种格式现在很少单独使用，我很惊讶go会这样做；Bouncy之所以支持它，只是因为OpenSSL支持它——而OpenSSL只是部分支持它，这是上个世纪的遗物。这就是说，如果您有有效的数据，Bouncy应该可以工作。（也是OpenSSL。）您可以发布一个完整的密钥，甚至是一个测试密钥吗？记住公钥密码的要点是公钥不是秘密的，甚至敌人都可以知道。对，公平点。我修改了原来的帖子，加入了一个完整的密钥。我的密钥生成肯定有问题——它生成的是ASN.1类型为0x62而不是0x02的整数。我修复了这个问题，因此上面的示例对于dumpasn1和“openssl asn1parse”都是可以接受的，使用您发布的密钥，并对您的代码进行javazing（这意味着它几乎是逐字逐句的），我没有得到任何异常并获得预期的输出。Dave，什么格式更好？我不想将其存储为实际的证书（至少我不这么认为）。。。我只是试图以某种合理的格式存储和传递RSA密钥对的公共部分。看起来很笨拙，使用X.509/PKIX证书——如果您没有真正的CA颁发证书，那么使用虚拟自签名证书——实际上是处理公钥的一种常见的常规方法（重要的是，PGP和SSH除外）。如果不想这样做，请使用X.509中的“SubjectPublicKeyInfo”结构——这是OpenSSL自2000年以来默认使用的结构，Java

Key

和

KeyFactory

（非对称）直接支持它——在DER（又称二进制）而不是PEM中，但是在不需要更改数据的情况下在这些数据之间进行转换是很容易的，即使没有弹性。您是否更改了数据以及截断了数据？它的一部分可能在一个有效的PKCS1公钥中，而不仅仅是偶然发生的，但是其他部分是完全错误的。这种格式现在很少单独使用，我很惊讶go会这样做；Bouncy之所以支持它，只是因为OpenSSL支持它——而OpenSSL只是部分支持它，这是上个世纪的遗物。这就是说，如果您有有效的数据，Bouncy应该可以工作。（也是OpenSSL。）您可以发布一个完整的密钥，甚至是一个测试密钥吗？记住公钥密码的要点是公钥不是秘密的，甚至敌人都可以知道。对，公平点。我修改了原来的帖子，加入了一个完整的密钥。我的密钥生成肯定有问题——它生成的是ASN.1类型为0x62而不是0x02的整数。我修复了这个问题，因此上面的示例对于dumpasn1和“openssl asn1parse”都是可以接受的，使用您发布的密钥，并对您的代码进行javazing（这意味着它几乎是逐字逐句的），我没有得到任何异常并获得预期的输出。Dave，什么格式更好？我不想将其存储为实际的证书（至少我不这么认为）。。。我只是试图以某种合理的格式存储和传递RSA密钥对的公共部分。看起来很笨拙，使用X.509/PKIX证书——如果您没有真正的CA颁发证书，那么使用虚拟自签名证书——实际上是处理公钥的一种常见的常规方法（重要的是，PGP和SSH除外）。如果不想这样做，请使用X.509中的“SubjectPublicKeyInfo”结构——这是OpenSSL自2000年以来默认使用的结构，Java

Key

和

KeyFactory

（非对称）直接支持它——在DER（又称二进制）而不是PEM中，但是，即使没有弹性，在不需要更改数据的情况下进行转换也很容易。