comments/questions

[Daniel Cabarcas]

Hi,

I pushed a small change, but here are some issues I wanted to discuss before addressing:

Line 295: I think it should be dimension 'n' and not phi(n).
Moreover, I think we should be consistent in the use of n as the dimension. For example in DiscreteGaussianPolynomialSamplerRejection, I think we should use n to denote the degree of the cyclotomic and a different letter, say N to denote the index of the cyclotomic, i.e. n=phi(N).
This is important when defining RingLWE, because as it stands right now, the underlying lattice dimension is phi(n) instead of n, so the security parameter should be phi(n), which creates some confusion.

line 553: I don't understand why classes RingLWE1 and RingLWE2 are necessary

line 679: perhaps it is better not to restart i to 0, and instead use $i\mod n$ for indexing. The reason is compatibility with the option of limiting the number of samples as in the LWE generator.

Regards

Daniel

[Martin Albrecht]

Hey,

On Friday 12 Apr 2013, Daniel Cabarcas wrote:
> Hi,
>
> I pushed a small change, but here are some issues I wanted to discuss
> before addressing:
>
> Line 295: I think it should be dimension 'n' and not phi(n).
> Moreover, I think we should be consistent in the use of n as the dimension.
> For example in DiscreteGaussianPolynomialSamplerRejection, I think we
> should use n to denote the degree of the cyclotomic and a different letter,
> say N to denote the index of the cyclotomic, i.e. n=phi(N).
> This is important when defining RingLWE, because as it stands right now,
> the underlying lattice dimension is phi(n) instead of n, so the security
> parameter should be phi(n), which creates some confusion.

+1

> line 553: I don't understand why classes RingLWE1 and RingLWE2 are
> necessary

Me neither :)

> line 679: perhaps it is better not to restart i to 0, and instead use
> $i\mod n$ for indexing. The reason is compatibility with the option of
> limiting the number of samples as in the LWE generator.

Good catch.

Go ahead with the fixes of (1) and (3) I'd say.

Cheers,
Martin

--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://martinralbrecht.wordpress.com/
_jab: martinr...@jabber.ccc.de

[Florian Göpfert]

Hi,

I think the classes RingLWE1 and RingLWE2 are only dummys because we
didn't know any "realistic" Ring-LWE-classes (like Regev or
LindnerPeikert for the matrix-version). I think that we should either
replace them by classes of Ring-LWE suggested in a paper (if we know
any) or simply remove them.

Florian

[Michael Schneider]

Hi,

the classes RingLWE1 and 2 where test instances that should allow people
to instantiate ringLWE, the same as LindnerPeikert and Regev. I'm ok
with removing them; maybe we can add instances from the NTRU-Paper, if
Daniel knows them better than I do.

I'm ok with all the other changes...

Best regards
Michael

[Daniel Cabarcas]

Hi
I added a RingLindnerPeikert class as an example of RingLWE Oracle.

Cheers

Daniel

--
You received this message because you are subscribed to the Google Groups "LWE Challenge" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lwe-challenge-devel+unsub...@googlegroups.com.
To post to this group, send an email to lwe-challenge-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/lwe-challenge-devel?hl=en-GB.