我正在使用较旧版本的OpenSSL，而且我遇到了一些在尝试使用跨平台代码时困扰我好几天的行为。
我有代码调用OpenSSL来签名。我的代码是在ASN1_sign中的代码之后建模的，该代码可以在OpenSSL的a_sign.c中找到，当我使用它时会出现相同的问题。以下是相关的代码行（在a_sign.c中找到并使用的方式完全相同）：
EVP_SignUpdate(&ctx,(unsigned char *)buf_in,inl);
ctx是OpenSSL使用的结构，与本讨论无关 buf_in是要签名的数据的char * inl是buf_in的长度
可以重复调用EVP_SignUpdate，以便在调用EVP_SignFinal进行签名之前读入要签名的数据。
在Ubuntu和Windows 7上使用此代码时，一切正常，在给定相同输入的情况下，它们都会产生完全相同的签名。
在OS X上，如果inl的大小小于64（即buf_in中有64个字节或更少），那么它也会产生与Ubuntu和Windows相同的签名。但是，如果inl的大小大于64，它会产生自己内部一致的签名，与其他平台不同。通过内部一致，我的意思是Mac会读取签名并验证它们是否合适，而它将拒绝来自Ubuntu和Windows的签名，反之亦然。
我设法修复了这个问题，并通过将上面的那行更改为以下内容来创建相同的签名，其中它一次读取一个字节的缓冲区：
int input_it;
for(input_it = (int)buf_in; input_it < inl + (int)buf_in; intput_it++){
EVP_SIGNUpdate(&ctx, (unsigned char*) input_it, 1);
}
这导致OS X拒绝其自己的数据签名＆gt; 64个字节无效，我在其他地方跟踪了一条类似的行，用于验证需要以相同方式分解的签名。
这修复了签名的创建和验证，但是仍然存在问题，因为我遇到了其他问题，而且我真的不想深入了解（并修改！）更深入OpenSSL。
当然我做错了，因为当我使用股票ASN1_sign时，我看到完全相同的问题。这是我编译OpenSSL的方式的问题吗？对于我的生活，我无法弄清楚。任何人都可以教育我必须做出的骨头错误吗？
答案 0 :(得分：1)
这可能是MacOS实施中的一个错误。我建议您按照http://www.openssl.org/support/faq.html#BUILD17
中的说明将上述文本发送给开发人员来提交错误答案 1 :(得分：0)
Mac上存在OpenSSL的已知问题（您必须跳过几个环节以确保它与正确的库而不是系统库链接）。你自己编译了吗？分发中的PROBLEMS文件解释了问题的详细信息，并提出了一些解决方法。 （或者如果您正在运行共享库，请仔细检查您的DYLD_LIBRARY_PATH是否已正确设置）。不能保证，但这似乎有可能开始......
答案 2 :(得分：-1)
移植Windows和Linux代码的最常见问题是内存的默认值。我认为Windows将其设置为0xDEADBEEF，Linux将其设置为0。