Segmentation fault: 11 in all de/serialization methods

[peiworld]

I get the libscarab working under 64Bit Mac. Pass the testsuit tests.

While I am trying to work with the python wrapper, I have problem with all de/serialization methods. Take this simple method as an example.

def test_mpz_serialization(self):
    print('begin')
    mpz = make_c_mpz_t()
    print('made mpz')
    stringified = serialize_c_mpz_t(mpz)
    print("after stringified")
    assert_equals(stringified, '0')

which trigger this method

def serialize_c_mpz_t(mpz): """ Serialize mpz_t

:type mpz: c_mpz_t
:rtype   : str
"""
c_str = lib_gmp.__gmpz_get_str(None, base, mpz)
if c_str == None:
    print "none"
else:
    print "has some thing"
result = string_at(c_str)
#.decode('ascii')
#libc.free(c_str)
return None

The nosetests failed at result = string_at(c_str). Would this be memory access problem? invalid memory? I confirm that same codes run fine under ubuntu build, using virtual machine in the same Mac.

Any idea?

[bogdan-kulynych]

I don't have a Mac to test it. Was it Python exception or segmentation fault?

[peiworld]

Not very sure, it seems something to do with memory access, as I highlighted in the codes.

Anyway, nice work. I am working on the C library directly.

Regards,

Peizhao Hu

On Oct 1, 2014, at 4:32 PM, Bogdan Kulynych notifications@github.com wrote:

I don't have a Mac to test it. Was it Python exception or segmentation fault?

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

[bogdan-kulynych]

Thanks.

Just to be sure, don't use this for anything serious. Smart-Vercauteren scheme is proved insecure for lattice dimensions less than 8192. libscarab uses dimension size 8 (sic!) and is very slow even with such a small parameter.

[peiworld]

Thanks for the reference.

So how bad is the performance? Should we chat directly using email? I would like to ask you a few thing about this FHE implementation.

Regards,

Peizhao Hu

On Oct 1, 2014, at 4:45 PM, Bogdan Kulynych notifications@github.com wrote:

Thanks.

Just to be sure, don't use this for anything serious. Smart-Vercauteren scheme is proved insecure for lattice dimensions less than 8192. libscarab uses dimension size 8 (sic!) and is very slow even with such a small parameter.

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

[andronat]

Hello @peiworld, you can find more information about benchmarks and things we calculated about the old scheme here: blindstore/blindstore#6 and blindstore/blindstore#10. I might miss some references so you can go check the general repository.

[peiworld]

Thanks for sharing the info. what is the parallelization?

[peiworld]

Hey guys, I just realized that the fhe_mul is multiplication at single bit level. so we can't use it directly to implement the function of multiplying two bit array, right?

[andronat]

No you can't and also is very slow. This is why using the FHE is impossible to build an application. And this is why we are implementing the V-DGHV scheme.

[peiworld]

any additional information on this scheme?

https://github.com/blindstore/blindstore/issues/21

I am exploring the idea of computation using FHE.

Like I said, I was extending the FHE implementation in C and realized the multiply is not really supported. I was trying to extend the lib to support subtraction and multiplication.

Any further pointer to the V-DGHV scheme will be great.

On Oct 3, 2014, at 5:08 AM, Anastasis Andronidis notifications@github.com wrote:

No you can't and also is very slow. This is why using the FHE is impossible to build an application. And this is why we are implementing the V-DGHV scheme

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