一份两百字的合同，一加密就报错
同事把整段合同文本贴进 RSA 加密框，点下去直接报错。他以为工具坏了，换浏览器、换电脑、折腾了半小时。真实原因很简单：RSA 天生装不下长文本，他撞的是密钥长度设下的硬上限。
能装多少，一笔账算清
按 RFC 8017 的 PKCS#1 v1.5 规则，单块最大明文等于密钥字节数减 11。1024 位密钥 128 字节，最多 117 字节；2048 位 256 字节，最多 245 字节；4096 位 512 字节，最多 501 字节。中文按 UTF-8 每个字 3 字节算，2048 位密钥塞得下 81 个汉字左右——两百字的合同当然装不进去。
- 1024 位：117 字节 / 约 39 个汉字，现在不建议再用
- 2048 位：245 字节 / 约 81 个汉字，当前默认档
- 4096 位：501 字节 / 约 167 个汉字，具体上限我按公式推的，没逐个实测
公钥加密私钥解，反过来就是签名
加密场景：对方用你的公钥加密，只有你的私钥能解。签名场景方向相反：你用私钥对摘要签名，任何人拿公钥都能验。签名不负责保密内容，它证明的是这段东西确实出自你手，且没被改过。
位数不是越大越好
1024 位已被主流拒绝，2048 位是现在的安全线，4096 位余量更大但每次运算更慢，高频握手场景会明显拖性能。慢多少取决于 CPU 和实现库，我在这台机器上没测，不报具体倍数。
填充别自己写
RSA 出错很少是因为数学，多半栽在填充：PKCS#1 v1.5 的校验没做严，历史上出过一批可被解密的实现。改用 OAEP 填充，用成熟库，别自己拼字节。自己实现一次，踩坑一次。
长数据怎么处理
标准解法是混合加密：随机生成一个 AES 密钥把正文加密，再用 RSA 只加密这把 AES 密钥。HTTPS 就是这么干的，RSA 负责传钥匙，AES 负责搬货。RSA 加解密工具 可以先跑一组小数据看流程。
常见问题
- 为什么报 data too large
- 明文超过单块上限。要么改用混合加密，要么拆块，别硬试。
- 公钥私钥能互换用吗
- 数学上可以，语义上不行。用错方向要么解密失败，要么签名验不过。
- 2048 位够用多久
- 按现有公开进展，2048 位在可预见期内够用；高价值长期数据直接用 4096 位。
- 能和 AES 一起用吗
- 这就是标准做法，RSA 加密 AES 密钥，AES 加密正文。