nav search
Data Centre Software Security DevOps Business Personal Tech Science Emergent Tech Bootnotes
BOFH
Lectures

back to article
SEAL up your data just like Microsoft: Redmond open-sources 'simple' homomorphic encryption blueprints

Lee D Silver badge

As a mathematician, this kind of thing interests me greatly.

But in terms of practical use it's very limited.

For instance, though it's *possible* to query an encrypted database... "It must be noted that... the authors have... used simple and non secure homomorphic scheme and still it takes a huge toll on the performance. For e.g. a 16 bit multiplication takes approximately 24 minutes."

This seems inherently impractical and it doesn't look like something we can parallelise in order to speed it up, or anything that any sufficiently large database (to be useful anyway) would be able to utilise in a general fashion for everyday queries.

Sure, you could farm off the database and all such computation to the cloud (that is after all the point - you ask an untrusted third party to do work on a database that they hold but cannot ever determine results or data from), but I can't see it being practical any time soon.

If a 16-bit multiplication takes 24 minutes, imagine how long any kind of complex SELECT statement is going to take, let alone whole-database UPDATE WHERE operations, etc.

Christian Berger Silver badge

It's research

No actual applications are currently on the horizon, but it might be usefull some day.

However we now have the situation of people peddling homomorphic encryption as the solution for the cloud. To those people I can simply only say, if you don't want others to get to your data, store and process it on your own computers.

TheVogon Silver badge

"and still it takes a huge toll on the performance"

Microsoft have solved that problem too:

https://www.theregister.co.uk/2018/05/24/boffins_from_microsoft_and_academia_cook_up_hardwaresecured_database/

zcf

The performance numbers you cite are not from this article and are unrelated to this work.

Homomorphic encryption has seen massive performance improvements over the past years. A single multiplication of such small numbers with SEAL would take around a millisecond. In an amortized setting the time would be closer to microsecond.

Search from O(billion) item data sets can be done with an encrypted query in seconds when done right. A complex SELECT-statement might be hard as SEAL at least is based on arithmetic circuits, whereas such queries may have much more convenient Boolean circuit representation.

Michael Wojcik Silver badge

Homomorphic encryption has seen massive performance improvements over the past years

Yes. I agree that we're now at the point where it looks practical for certain niche application domains.

I'm looking forward to seeing similar improvements in verifiable computation, which would address some similar problems for distributed computation for some application domains. The "nearly practical" Pinocchio system was introduced, what, three years ago? Haven't looked into what's been happening in this area since.

el kabong

Tech that creates more problems than it solves

Perhaps this one will fail but you cannot blame them for not trying. Tech that creates more problems than it solves has been paying microsoft very good dividends for quite long, definitely a keeper!

I can see that microsoft still retains its business acumen.

Anonymous Coward
Anonymous Coward

Chinese walls.

This was something IBM are working on (I had a visit to Hursley a while back) that was of interest for organisations that have distinct datasets they want to share, but haven't got the regulatory or GDPR agreements for. In our case it was insurers and trying to match policy and marketing details.

If you hold them in a Homomorphic database, then you can query them without breaching data protection or regulatory issues. The queries have to be predefined. You can't run an ad-hoc "SELECT * FROM Customers", but you can run "SELECT SUM (premiums) FROM Customers WHERE CustomerID IN (SELECT ProspectID FROM MarketingDB.Prospects)

Ian Michael Gumby Silver badge

Re: Chinese walls.

I agree but there are better ways to handle this problem that are going to be much more efficient.

And even if the data is encrypted, you can break your Chinese wall.

ThatOne Bronze badge
Coat

My crystal ball is ringing

I see, I see - unauthorized users working illegally with the database without any need to decrypt it...

zcf

Re: My crystal ball is ringing

Perhaps, but they benefit nothing unless the data owner helps them decrypt their results. This is the whole point of this technology.

Mr Benny

Surely the point of encryption...

... isnt just to hide the data but also to prevent tampering. This sounds a lot like the latter. Why would you want to use this if anyone could just come along and change your data (albeit without ever knowing what it was)?

diodesign (Written by Reg staff) Silver badge

Re: Benny

"Why would you want to use this if anyone could just come along and change your data (albeit without ever knowing what it was)?"

No one can "just come along" and change it - if you have unauthorized database access then if the DB is unencrypted t's completely game over, and if it's encrypted then at least they can't see the data. If someone breaks in and changes the database records, then roll back to a backup and seal up your network security.

The aim of this is to keep the data shielded and minimize risk.

C.

Carpet Deal 'em
Boffin

Re: Surely the point of encryption...

Encryption is to hide things from prying eyes. If you want to prevent tampering, you need to use signatures. Technically they're both forms of cryptography, but they're still very much different things.

Mr Benny

Re: Benny

"if you have unauthorized database access then if the DB is unencrypted t's completely game over, "

If you have authorised access then you can decrypt it anyway presumably so what exactly is the point of this method?

Mr Benny

Re: Surely the point of encryption...

" If you want to prevent tampering, you need to use signatures."

You don't even need that, you could just generate a hash. But the whole point of this seems to be to allow operations to be carried out on the encryoted data without that data ever being seen. Whenever you do this the hash will change but there is no way of knowing direction what has been changed. I'm really struggling to see the point of this system.

Michael Wojcik Silver badge

Re: Surely the point of encryption...

If you want to prevent tampering, you need to use signatures.

You need to provide data integrity against active attacks. Signatures are one primitive for that, but they're generally not appropriate for this use case. HMAC and similar constructs, using cryptographic digests but not asymmetric cryptography, are more plausible.

Michael Wojcik Silver badge

Re: Surely the point of encryption...

But the whole point of this seems to be to allow operations to be carried out on the encryoted data without that data ever being seen. Whenever you do this the hash will change

Not if it's a read operation. Some databases aren't write-only.

That said, there are use cases for a blind update mechanism. The simple ones can generally be done trivially without using something like homomorphic encryption, given a typical threat model. (For example, letting a partner increment a customer's number-of-items-purchased without seeing the original value; that can be trivially done with a stored procedure.) But for example it may be useful to let an authorized party bulk-read encrypted data, perform computations for a report (still encrypted, because homomorphism), and write that report back to the database. That gives you a way to offload things like report generation without compromising privacy.

but there is no way of knowing [directly?] what has been changed

I have no idea what you mean by this. Any entity with the decryption key can see the new value, and it's entirely possible to do all the usual auditing and so forth if you need a log of changes. An entity which is authorized to make blind updates - i.e. can update data but not decrypt it - shouldn't be able to tell what was changed, at least in terms of the decrypted values. So what's the problem?

Sureo

"99 per cent accuracy"

1,000,000 operations, 10,000 errors ... how is that useful?

Michael Wojcik Silver badge

Re: "99 per cent accuracy"

1,000,000 operations, 10,000 errors ... how is that useful?

If only it were possible to detect and correct errors...

blue-eyes

Qubits for all

Bring on quantum computers to solve the speed issue

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

The Register - Independent news and views for the tech community. Part of Situation Publishing