You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Situation: To create a proof for a message using VRF prove() and when it's used the verify() with the same message, it could fail.
Caused by: a bug in passing the message from Go to C as a byte array. Specifically, it must pass an address of the array (so-called pointer or reference), but it was passed not array address but Go slice address as follows:
The &message specifies not array address but slice address.
messagePrt:= (*C.uchar)(unsafe.Pointer(&message[0]))
// or C.NULL if len(message) == 0
When proof() and verify() were using exactly the same instance of the message []byte slice, verification seemed to succeed because the contents pointed to by both addresses were equal. However, in case that the slices had the same data but different instances, it failed because the data pointed to by the slice addresses where different. This was essentially a memory access violation and could have caused a SIGSEGV.
Fixed: in PR #12 . This issue has been created to share the issue.
The text was updated successfully, but these errors were encountered:
Situation: To create a proof for a message using VRF
prove()
and when it's used theverify()
with the same message, it could fail.Caused by: a bug in passing the message from Go to C as a byte array. Specifically, it must pass an address of the array (so-called pointer or reference), but it was passed not array address but Go slice address as follows:
The
&message
specifies not array address but slice address.When
proof()
andverify()
were using exactly the same instance of themessage []byte
slice, verification seemed to succeed because the contents pointed to by both addresses were equal. However, in case that the slices had the same data but different instances, it failed because the data pointed to by the slice addresses where different. This was essentially a memory access violation and could have caused a SIGSEGV.Fixed: in PR #12 . This issue has been created to share the issue.
The text was updated successfully, but these errors were encountered: