Samples semiHonestOT and maliciousOT do not seem to work properly

[fabrice102]

On a fresh install on Ubuntu 16.04 (commit 796e73f - master branch), I get the following results:

# semi-honest
$ ./libscapi_example semiHonestOT 1
Waiting for receiver to connect on port: 7766
Receiver connected
PrecomputeNaorPinkasSender and OTExtensionSender init took: 38 ms
x0 :
255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
x1 :
255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255

$ ./libscapi_example semiHonestOT 2
187 106 89 176 60 101 136 233 199 74 144 227 205 154 108 120

# malicious
$ ./libscapi_example maliciousOT 1
OT verification unsuccessful
x0 :
161 103 203 6 38 23 129 202 144 243 91 0 220 3 199 179
x1 :
110 103 8 99 185 100 54 234 219 165 130 44 25 20 135 245

$ ./libscapi_example maliciousOT 2
Error at position i = 0, k = 0, with X1 = 6e and res = 7e
126 244 14 71 246 185 251 141 69 36 74 223 123 159 116 137

For the semi-honest case, I think the reason is the following: in https://github.com/cryptobiu/libscapi/blob/796e73f69/src/interactive_mid_protocols/OTSemiHonestExtension.cpp#L235, libscapi implicitly assumes that the function send will update x0 and x1, while it does not (see https://github.com/cryptobiu/libscapi/blob/796e73f69790b96e676464884df994a481364db5/lib/OTExtension/ot/ot-extension.cpp#L301).

For the malicious case, I have no idea what the problem is. However, on macOS (see #25), libscapi_example just segfaults in the malicious case (but not in the semi-honest case, where it works as on Ubuntu 16.04).

[fabrice102]

35 was a bug, but fixing it is not sufficient.

For information, here is what valgrind tells me (after fixing #35):

==30660== Invalid read of size 1
==30660==    at 0x62884D0: maliciousot::CBitVector::XORBytesReverse(unsigned char*, int, int) (cbitvector.cpp:253)
==30660==    by 0x628F955: maliciousot::Mal_OTExtensionReceiver::BuildMatrices(maliciousot::CBitVector&, maliciousot::CBitVector&, int, int, unsigned char*) (ot-extension-malicious.cpp:239)
==30660==    by 0x628F525: maliciousot::Mal_OTExtensionReceiver::OTReceiverRoutine(int, int) (ot-extension-malicious.cpp:130)
==30660==    by 0x6293619: maliciousot::Mal_OTExtensionReceiver::OTReceiverThread::ThreadMain() (ot-extension-malicious.h:342)
==30660==    by 0x629332D: maliciousot::CThread::ThreadMainHandler(void*) (thread.h:153)
==30660==    by 0x58EF6B9: start_thread (pthread_create.c:333)
==30660==    by 0x6E923DC: clone (clone.S:109)
==30660==  Address 0x781a490 is 0 bytes after a block of size 16 alloc'd
==30660==    at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30660==    by 0x6287BE2: maliciousot::CBitVector::Create(int) (cbitvector.cpp:67)
==30660==    by 0x48518C: OTExtensionMaliciousReceiver::runOtAsReceiver(std::vector<unsigned char, std::allocator<unsigned char> >&, int, int, unsigned char) (in /home/fbenhamo/libscapi/samples/libscapi_example)
==30660==    by 0x4854BB: OTExtensionMaliciousReceiver::transfer(OTBatchRInput*) (in /home/fbenhamo/libscapi/samples/libscapi_example)
==30660==    by 0x451B53: mainR() (in /home/fbenhamo/libscapi/samples/libscapi_example)
==30660==    by 0x451E86: mainOTMalicious(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) (in /home/fbenhamo/libscapi/samples/libscapi_example)
==30660==    by 0x418AEA: main (in /home/fbenhamo/libscapi/samples/libscapi_example)

[fabrice102]

For information, on the receiver side, it seems that, at this point in the code https://github.com/cryptobiu/libscapi/blob/796e73f69790b96e676464884df994a481364db5/lib/MaliciousOTExtension/ot/ot-extension-malicious.cpp#L237 rowbytelen = 32 while m_nChoices.GetSize() = 16, hence an overflow. I don't understand enough the code to debug it further.