Timing Attack Vulnerabilities in Multiple Implementations

[paragonie-scott]

http://www.openwall.com/lists/oss-security/2016/01/24/10

[LookingSharp]

Are you saying the timing vulnerability exists in the swift version? Looking at the code, I see isEqualInConsistentTime is used to compare data. Does this vulnerability exist in this version?

[rnapier]

The ObjC and Swift implementations of RNCryptor (which are the primary implementations) do use constant-time hash comparisons. Have you found otherwise? The most common server side implementation is PHP, which also does constant-time hash comparisons (currently, though this took longer to get fixed then I liked).

I didn't write and don't directly support all the implementations, but please feel free to open issues on any implementations with this or any other error. RNCryptor defines a format. It has several implementations that various developers maintain.

If you believe there is any defect in the Swift or ObjC implementations, I am happy to look at that here, but this repository doesn't cover all the independent implementations of the format. GitHub doesn't have any way to manage organization-level issues, so a separate issue is required on each repository.

Thanks.

[paragonie-scott]

Are you saying the timing vulnerability exists in the swift version?

No, I thought this was the main repo for the entire project.

GitHub doesn't have any way to manage organization-level issues, so a separate issue is required on each repository.

I'm sure the people who maintain the language implementations are responsible folks who keep up on security matters and won't need me to tell them individually.

[rnapier]

That's fine. But if you found specific implementations that had trouble, please let me know. I'm happy to open the issues myself. I'll go ahead and audit them all, but if you've already done some of it, that'll save me some time.

Thanks for the notice.

[paragonie-scott]

https://github.com/RNCryptor/rncryptor-hs/blob/958630b09daad60d0115400c2e37cfdd9627ffa3/src/Crypto/RNCryptor/V3/Decrypt.hs#L110-L124

My Haskell kung-fu is weak; is this just discarding the MAC entirely?

[rnapier]

Yes. I believe it is discarding it.

[paragonie-scott]

I made a note in RNCryptor/rncryptor-hs#2

[paragonie-scott]

OK, I think I found all the variable-time MAC validation flaws in the various implementations. I think there might be questionable choices w.r.t. the CSPRNG implementations on some of them, but until I research that in depth I don't feel comfortable raising the alarm.

Have fun.

[rnapier]

Thank you. Always glad to have extra eyes on these things.

On Jan 24, 2016, at 10:41 PM, Scott [email protected] wrote:

OK, I think I found all the variable-time MAC validation flaws in the various implementations. I think there might be questionable choices w.r.t. the CSPRNG implementations on some of them, but until I research that in depth I don't feel comfortable raising the alarm.

Have fun.

—
Reply to this email directly or view it on GitHub.

[adinapoli]

@paragonie-scott @rnapier hey folks, made a note about HMAC validation here (happy to accept pointers):

RNCryptor/rncryptor-hs#2