Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segmentation fault: 11 in all de/serialization methods #1

Open
peiworld opened this issue Sep 30, 2014 · 9 comments
Open

Segmentation fault: 11 in all de/serialization methods #1

peiworld opened this issue Sep 30, 2014 · 9 comments

Comments

@peiworld
Copy link

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
Copy link
Contributor

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

@peiworld
Copy link
Author

peiworld commented Oct 1, 2014

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 [email protected] 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
Copy link
Contributor

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
Copy link
Author

peiworld commented Oct 1, 2014

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 [email protected] 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
Copy link

andronat commented Oct 1, 2014

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
Copy link
Author

peiworld commented Oct 1, 2014

Thanks for sharing the info. what is the parallelization?

@peiworld
Copy link
Author

peiworld commented Oct 2, 2014

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
Copy link

andronat commented Oct 3, 2014

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
Copy link
Author

peiworld commented Oct 3, 2014

any additional information on this scheme?

blindstore/blindstore#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 [email protected] 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants