2010-08-03 69 views
6

我正在使用較舊版本的OpenSSL,並且遇到了一些行爲,這些行爲在嘗試使用跨平臺碼。在Mac OS X上生成與Windows和Linux不同的結果的相同C代碼

我有調用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拒絕將自己的數據> 64字節的簽名視爲無效,並且我在其他地方跟蹤了一條類似的線,以驗證需要以相同方式分解的簽名。

這修復了簽名的創建和驗證,但仍然出現了問題,因爲遇到了其他問題,而且我實際上不想在OpenSSL中更加深入地進行拖拽(並修改!)。

當然,我做錯了什麼,因爲我在使用庫存ASN1_sign時看到完全相同的問題。這是我編譯OpenSSL的方式問題嗎?對於我的生活,我無法弄清楚。任何人都可以教我關於我一定會犯的什麼骨頭錯誤嗎?

回答

-1

移植Windows和Linux代碼時最常見的問題是內存的默認值。我認爲Windows將其設置爲0xDEADBEEF,並將Linux設置爲0。

0

在mac上有OpenSSL的已知問題(你必須跳過一些箍環以確保它與正確的庫而不是系統庫鏈接)。你自己編譯了嗎?發行版中的PROBLEMS文件解釋了該問題的詳細信息,並提出了一些解決方法。 (或者如果您使用共享庫運行,請仔細檢查您的DYLD_LIBRARY_PATH是否已正確設置)。沒有保證,但這看起來是一個可能的地方開始...

相關問題