NTRUEncrypt and NTRUSign in Java
der_be...@hotmail.com
Java sources for NTRU encryption and signatures are available at:
http://sourceforge.net/projects/ntru/
Comments and critique are welcome.
Greetings, Heinrich
Joseph Ashwood
news:2da24eae-12ed-407c...@o30g2000pra.googlegroups.com...
> Java sources for NTRU encryption and signatures are available at:
> http://sourceforge.net/projects/ntru/
First I'd like to say that it is great to see some interest in alternatives
to the normal ones, and while I still have reservations about NTRU's
security, I encourage learning and research.
I haven't taken a look at the implementation itself, so for now I'll just
assume its correct. The structure doesn't look to be the easiest to use. It
seems based on a C implementation, I would like to see a object oriented
design. Looking in your test code I see things like
encrypted = NtruEncrypt.encrypt(plainText, kp.pub, params);
Instead, I would have prefered to see
encrypted = kp.encrypt(plaintext);
In an object-oriented system like Java your objects should carry their own
data with them, or at least a reference. The same applies to
byte[] priv2 = kp2.priv.getEncoded();
I would have preferred to see simply
kp2.getPrivate()
or
kp2.getPrivate(SignatureKeyPair.RAWBYTES)
Making changes like these throughout the code would make it much more
usable.
You should also extend your documentation to cover the key selection
process, that is the part of the NTRU algorithms that has posed the greatest
problems and gone through the most revisions over the years.
Joe
Tom St Denis
> wrote in messagenews:2da24eae-12ed-407c...@o30g2000pra.googlegroups.com...
>
> > Java sources for NTRU encryption and signatures are available at:
> >http://sourceforge.net/projects/ntru/
>
> First I'd like to say that it is great to see some interest in alternatives
> to the normal ones, and while I still have reservations about NTRU's
> security, I encourage learning and research.
I was going to add it to LTC when I was in college but I was told by
folks who own the patents they would sue me if I did. Their loss.
Tom
Noob
> I was going to add it to LTC when I was in college but I was told by
> folks who own the patents they would sue me if I did. Their loss.
Patents on algorithms are hindering progress.
Europe and Asia should take their ball and go home,
ignoring every such patent from the US of A.
Tom St Denis
The larger issue is the length patents are valid (well and what sort
of nonsense can get patented). I don't think anyone is arguing in
this case that NTRU wasn't original enough. What annoyed me though
was that part of the LTC project was research and I was very much so
going to pit it against RSA and ECC. They decided not to participate
[by letting me add it]. Of course look at how many people are using
it.
If patents were shorter length we'd see way more innovation since it'd
allow companies to grow off the back of their R&D labour but to not
rest on their laurels too long. Most people I chat with think 5 years
is plenty long for a tech related patent in this day and age.
Other companies have their act together. Atmel for instance, when
they came out with the AVR32 platform I asked them if they could send
me a sample so I could port TFM to it. Not only did they think that
was a cool idea they mailed me a FREE developers kit [board+BSP+etc].
I think I still have it somewhere... I was able to port TFM to it and
get benching data fairly quickly. Their FAE even provided email
support.
I've tried the same request with ARM to no avail. ARM support rocks
(I work with their tools professionally now...) but their FAE/Sales
don't really appreciate OSS (or at least didn't when I was active on
LTC) as much.
When I worked at AMD they encouraged OSS development and were all cool
with benchmarks [specially since at the time I was pitting it against
the Pentium 4 and M which were much slower than the K8]. AMD was
actually an interesting experience since during the hiring process
their HR staff actually researched my projects and wrote it into my
contract that my OSS work was acceptable, to be done on my own time,
is my own work product, etc. I was really surprised to see them chat
about it to be honest since most HR staff don't do that sort of
background work.
I've done contracts for another company (they make wifi/bluetooth
chips ... figure it out) where they had no such provisions. I
remember one contract where I required them to write in an OSS
provision to which the hiring manager agreed but to have the contract
accepted by them a VP would have to sign off on it. This was on a
Friday at like 2pm. They had to call one at home to come in [or find
a fax machine] to fax in a sign off page. I felt bad about ruining
their day but it meant that they didn't own LTC. Working for them was
a breeze since they did agree to the terms but they obviously weren't
prepared to work with someone who works on OSS.
So some companies get that open research is a good idea, and some
don't.
Tom
Scott Contini
> wrote in messagenews:2da24eae-12ed-407c...@o30g2000pra.googlegroups.com...
>
> > Java sources for NTRU encryption and signatures are available at:
> >http://sourceforge.net/projects/ntru/
>
> First I'd like to say that it is great to see some interest in alternatives
> to the normal ones, and while I still have reservations about NTRU's
> security, I encourage learning and research.
>
A very significant result on NTRU has been accepted to
Eurocrypt 2011 this year:
Title: Making NTRU as Secure as Worst-Case Problems over Ideal
Lattices
Authors: Damien Stehle and Ron Steinfeld
I haven't read it myself but this seems to be what is
needed to give the cryptosystem credibility.
> I haven't taken a look at the implementation itself, so for now I'll just
> assume its correct. The structure doesn't look to be the easiest to use. It
> seems based on a C implementation, I would like to see a object oriented
> design. Looking in your test code I see things like
> encrypted = NtruEncrypt.encrypt(plainText, kp.pub, params);
>
> Instead, I would have prefered to see
> encrypted = kp.encrypt(plaintext);
>
> In an object-oriented system like Java your objects should carry their own
> data with them, or at least a reference. The same applies to
> byte[] priv2 = kp2.priv.getEncoded();
>
I'm not an expert in Object Oriented coding, but
I have reservations about the design philosophy for
security applications. Making inputs to a function
explicit has the advantage that a code reviewer can
easily follow the control flow and know where the data
comes from. Putting the data within the objects can
easily lead to complex code that can make it difficult
to trace the source of data.
Scott
der_be...@hotmail.com
>
> I was going to add it to LTC when I was in college but I was told by
> folks who own the patents they would sue me if I did. Their loss.
It's annoying, and it is why the NTRU project on SourceForge only
releases source code.
Tom St Denis
LTC was source only too. They still threatened me just the same. I'd
check with NTRU [or whomever owns the patents] that you're in the
clear. It's not an algorithm worth losing your home over.
Tom
der_be...@hotmail.com
>
> LTC was source only too. They still threatened me just the same. I'd
> check with NTRU [or whomever owns the patents] that you're in the
> clear. It's not an algorithm worth losing your home over.
They must have calmed down since then because after they made a few
vague threats, they started negotiating and are now okay with the code
being released under a non-profit open source license.
It seems scare tactics and BS are part of their business model. Not
that that's anything unusual.