
Simple Encrypted Arithmetic Library goes open source - dsr12
https://www.microsoft.com/en-us/research/blog/the-microsoft-simple-encrypted-arithmetic-library-goes-open-source/
======
tuxxy
To give some context, this is moving away from Microsoft's "open source"
license that basically requires you to give Microsoft access to whatever you
make with their libraries.

Moving to MIT is great for this. As someone working on FHE, we'll finally be
able to see some interesting applications with this library other than
Microsoft's research. Great job to the SEAL team!

~~~
umvi
What does FHE stand for? All my searches are leading to religious articles
about spending time with your family

~~~
emadelwany
I believe they're referring to Fully Homomorphic Encryption [1]

[1]
[https://en.wikipedia.org/wiki/Homomorphic_encryption#Fully_h...](https://en.wikipedia.org/wiki/Homomorphic_encryption#Fully_homomorphic_encryption)

------
newfocogi
I am not an encryption expert, but to the casual techy follower, homomorphic
encryption seems like it could be huge for the union of machine learning and
digital privacy. Are there any experts on HN who could comment on how mature
this technology is? Or does anyone know of any interesting projects that use
this? I know Numerai is using something of this sort, but it is hard for me to
tell how legitimate it is.

~~~
osaariki
I work at Microsoft Research with the SEAL team on applications for Fully
Homomorphic Encryption (FHE). Batched integer FHE schemes are great for
machine learning. The regular data access patterns in neural networks make
using the batching easy and the rather "wide" computations lead to good
encryption parameters. Also a new scheme, CKKS, gives the ability to divide by
certain plaintext constants, which helps control scaling in fixed point
representations. This comes in exchange for results being approximate, which
is not a problem in machine learning.

Currently what FHE needs is better toolchain support. Selecting encodings and
encryption parameters is hard, but a lot can be done with good language
support and tooling. We're presenting some of our work on automatically
selecting good data layouts for NNs on FHE at the PPML workshop in NIPS next
weekend [1].

[1] [https://ppml-workshop.github.io/ppml/](https://ppml-
workshop.github.io/ppml/)

------
polskibus
What are the performance costs of using such library vs raw data operations?

~~~
garganzol
To give you an estimate: an AES encryption operation takes about 2 seconds to
compute in homomorphic encrypted domain on a generic machine.

Non-encrypted AES operation is approximately 10.000.000 times faster.

~~~
polskibus
I understand that initial encryption costs a lot, that can be one-off though.
My question was more about the computation on data - whether the same
computation (using this library?) on homomorphically encrypted data is
performing as well as on unencrypted data? Is there a penalty to pay on every
operation after initial encryption?

------
CephalopodMD
Has anyone tried to use this to create a distributed cloud? If storage and
certain types of computation could be encrypted, anyone could sell their spare
computation power without trust issues.

~~~
UncleMeat
Somewhat Homomorphic Encryption unfortunately only works for a pretty limited
set of workloads and FHE is still mind bogglingly slow so a general purpose
cloud for arbitrary computation isn't going to be a thing any time soon.

~~~
CiPHPerCoder
Also, by itself, homomorphic encryption doesn't protect against chosen-
ciphertext attacks, which makes it very unattractive for 99.9% of real world
crypto use-cases.

[https://tonyarcieri.com/all-the-crypto-code-youve-ever-
writt...](https://tonyarcieri.com/all-the-crypto-code-youve-ever-written-is-
probably-broken)

In my experience, a lot of teams also reach for FHE to solve problems that are
easily and securely solved without it (i.e. searchable encryption):

[https://github.com/paragonie/ciphersweet](https://github.com/paragonie/ciphersweet)

That being said, there is the 0.01% problem space where FHE makes perfect
sense (mostly in the realm of encrypted databases and machine learning). For
those systems, if the database can ever be considered adversarial (your threat
model may rule this out, most applications' do not), a simple construction
involving HMAC, a secure digital signature algorithm, and an append-only
ledger can protect the application that reads from the database against
chosen-ciphertext attacks.

[https://paragonie.com/blog/2017/12/assuring-ciphertext-
integ...](https://paragonie.com/blog/2017/12/assuring-ciphertext-integrity-
for-homomorphic-cryptosystems)

~~~
Ar-Curunir
Why does lack of CCA security make FHE unattractive? The entire point of FHE
is to allow malleability of ciphertexts.

~~~
CiPHPerCoder
CCAs have historically been useful for defeating the confidentiality
guarantees of cryptography protocols. BB'98, Vaudenay '02, the iMessage
attack, etc.

Selling "encryption, but not IND-CCA3" to a lot of (clueful, at least)
companies is almost impossible.

If you read the linked article, it discusses a way to hack it in.

------
gadders
In case anyone else wondered:
[https://en.wikipedia.org/wiki/Homomorphic_encryption](https://en.wikipedia.org/wiki/Homomorphic_encryption)

"Homomorphic encryption is a form of encryption that allows computation on
ciphertexts, generating an encrypted result which, when decrypted, matches the
result of the operations as if they had been performed on the plaintext."

------
wwarner
Helpful! This kind of encryption is required to make relational data secure.
[https://arxiv.org/pdf/1512.03498.pdf](https://arxiv.org/pdf/1512.03498.pdf)

------
patwolf
I recall several years ago hearing about other companies, particularly IBM,
patenting technologies related to homomorphic encryption. I wonder if there is
any risk to some of this infringing on a patent and what that means for users
of OSS when that happens.

------
ocdtrekkie
Isn't the "SEAL" acronym a bit overloaded in the realm of cryptography?
[https://en.wikipedia.org/wiki/SEAL_(cipher)](https://en.wikipedia.org/wiki/SEAL_\(cipher\))

~~~
marshray
I'd never heard of it, a web search turns up only a handful of mentions, and
it's not even the only thing in crypto to be called 'seal'.

~~~
ocdtrekkie
I figured it wasn't the only one. People who have gone through Cisco material
have an outsize exposure to this particular flavor of SEAL because it's one of
the few presented alternatives to AES in their material:
[https://security.stackexchange.com/questions/141879/cisco-
sa...](https://security.stackexchange.com/questions/141879/cisco-says-
software-optimized-encryption-algorithm-seal-is-more-secure-than-ae)

------
tonetheman
Not simple. But super cool stuff

------
ancarda
I know very little about C, C++, or Rust, so I want to ask this to understand
why C++ was picked for this. My limited understanding is that people were
tolerating C++ libraries like OpenSSL, but that new crypto or security code
would likely be written in Rust for safety.

The blog doesn't say much (to me) about the choice:

    
    
        In addition to having no external dependencies, Microsoft SEAL
        is written in standard C++, making it easy to compile in many
        different environments.
    

Is Rust unsuitable for this project? If anyone here worked on SEAL, I'd love
to learn more about this -- did the SEAL team consider using Rust?

~~~
dpark
> _My limited understanding is that ... that new crypto or security code would
> likely be written in Rust for safety._

Where did you get that impression? The creators of Rust would undoubtedly love
that to be the case, but Rust is still essentially in its infancy. To my
knowledge there are almost no major projects released that have been built in
Rust. It's ranked below such heavy hitters as Ada and Prolog for popularity on
the TIOBE index[1]. It's pretty unlikely that Rust will become the standard
language for everything crypo- or security-related anytime soon (or ever, but
it could happen).

[1] [https://www.tiobe.com/tiobe-index/](https://www.tiobe.com/tiobe-index/)

~~~
steveklabnik
> there are almost no major projects released that have been built in Rust.

[https://news.ycombinator.com/item?id=18545373](https://news.ycombinator.com/item?id=18545373)

This includes Microsoft, which I forgot in that post, who uses it in
production for their IOT product, and as part of Visual Studio Code.

That said, for crypto, there are some less than ideal things. That’s not
stopping projects from working on it.

~~~
dpark
To be clear, I did not claim no one was using it. "Almost no major projects"
implies there there _are_ a few major projects. It's a small set of projects,
though, especially in comparison with something like C++.

~~~
steveklabnik
Yep, that’s very much true. It’s been on a big upward trajectory lately. But
that’s easy when you’re starting small :)

------
ainiriand
Never roll out your own crypto.

~~~
dpark
When people say "never roll your own crypto", they mean _you_ , the amateur
who doesn't have the experience, expertise, or scale to get it right. They
don't mean that literally no one should ever write crypto code.

~~~
WorldMaker
Yes, if there are experts today on homomorphic encryption, one would assume
that Microsoft's department of Cryptographic Research plausibly includes some
(if not all) of them.

Their publications are online, if one wants to see what peer reviewed works
they've published: [https://www.microsoft.com/en-
us/research/group/cryptography-...](https://www.microsoft.com/en-
us/research/group/cryptography-research/)

------
craftyguy
Perhaps someone can explain why this can be trusted? microsoft has a long
history of cooperating with governments across a broad range of oppressiveness
(e.g. US, China, etc). I wasn't able to quickly/easily find any peer reviews
of this implementation. Without any more information, how do we know this
isn't backdoored in some way?

~~~
pwaivers
I believe releasing it to open source makes the code more trustworthy. Now,
anyone can go in and verify how it works. Any backdoor would be visible in the
code.

~~~
craftyguy
> I believe releasing it to open source makes the code more trustworthy

I don't, and I think it's dangerous to assume that. Many open source projects
have systems in place for publicly reviewing and approving code, but microsoft
does not have a history of conducting public code reviews for their projects.
I would never assume that publicly viewable code is being reviewed by others
who know what they are doing if it's not obvious that they are.

> Now, anyone can go in and verify how it works. Any backdoor would be visible
> in the code

I would only trust those with a high degree of mathematical knowledge,
specifically around the subject of cryptography to be able review the code in
any meaningful way. The rest of us can verify that it builds successfully and,
well, that's about it.

~~~
jf-
Be that as it may, if you’re trying to hide something releasing it as open
source is a pretty terrible way to do it.

~~~
craftyguy
Not if it's highly unlikely anyone with enough knowledge to know otherwise is
going to review it. The upside is that you get folks like the one above who
automatically assume open source software is safe, and use it.

~~~
jf-
Or just don’t bother open sourcing it and running the risk of being caught. In
principle I agree with you, but in practical terms it would be a very wacky
double bluff to pull.

