IBM completes successful field trials on Fully Homomorphic Encryption
arstechnica.com
arstechnica.com
That's because FHE-encrypted software is locally unhackable as long as its implementation of FHE remains unbroken.
Think:
* FHE-encrypted mobile operating systems, applications, and data.
* FHE-encrypted desktop and server operating systems, applications, and data.
* FHE-encrypted "smart home" devices -- from light bulbs to dishwashers to fridges.
* FHE-encrypted transportation infrastructure -- from automobiles to trains to airplanes.
* FHE-encrypted industrial machinery of all kinds.
If FHE ever becomes practical, we're looking at a very unhackable future.
Remarkably, I've never seen this issue mentioned anywhere else before.
Unless the key is kept locally, which would be hackable.
I'm also seeing some questions over side channel attacks by throwing enough data at the polynomial transforms that make up the NAND gate you're hiding the FHE'd data in, some people are claiming there has to be a way to eventually derive the encrypted value of the data you're attacking, but I don't understand any of the maths around FHE so I can't tell how big a concern those types of attacks are. From my layman's interpretation of the comments IBM'ers are responding to, I don't think a single operation under FHE is intrinsically vulnerable to side channel attacks, but I bet how FHE is used in real-world applications with iterative back-and-forth operations does potentially open up specific poorly-designed usage patterns to the classic inferential side channel attacks.
If FHE becomes practical at the scale you imagine, it would dramatically raise the bar on hacking for sure, but the implementers still only need to make one mistake to give a wedge to the hackers to work with.
The tokenization market (tokenize/detokenize sensitive data) just turned up the "interesting" knob to 11, though. Would take a lot of work between vendors to make real and practical, but some real promise there.
The killer thing is the performance penalty for doing FHE on any dataset of meaningful size. This is because if you want to do an operation on one member of the set you need to do an operation on all members of the set otherwise you leak which member you care about. For sets of a very small size this performance penalty might be ok. For sets of a large size, like the set of all users of a service, the performance penalty will grow at least linearly to the size of the set.
This is the problem at the core of ZK-style proving systems. You can push the proof construction work into the client and have a sub-linear verification time relative to the proof, but the proof construction in the first place is going to be slow and expensive (and slower as the size of the set increases!).
The edge of research here is being done by cryptography labs all around the world. If someone does manage to solve this in a purely-software based manner with a performance penalty that is acceptable for a monotonically increasing set, that’s the holy grail. I remain unconvinced that this will be solved in a reasonable fashion for this use case in my lifetime (but I would be thrilled to be proven wrong!!). If you know of research which makes inroads on this problem, please point me at it.
Currently it's a wet dream for a lot of businesses.
Note: I work on a system design that I believe is acceptable that uses Intel’s SGX which we detail in this tech talk entitled “why sgx”: youtube.com/watch?v=Hwf_Q31woLo&utm .
I'm of the understanding that you send me ciphertext, I transform it with some operations you define, and I send back ciphertext-v2.
I can discern how this could exfiltrate data safely. They send in a bunch of zeros and I fill in a one for each minute I used this lightbulb, by dynamically creating the FHE circuit to reflect the data saved.
It's not clear to me how this could change my lightbulb. By 'change' I mean 'affect the behavior' or update the firmware or something. I say this with the expectation that the blobs I received and produced are ciphertext on my side, without keys to decrypt it (unlike, say, dvd drm).
And locally unreadable.
In all of the use cases you have mentioned, FHE machine on the user device, can not perform interactions(IO, etc..) with the outside world (can't connect to a network, can't display things on a screen, etc..) without the key. So for these devices to be useful, the keys will have to be embedded in the IO paths(in which case the device would be hackable) or FHE machine should be implemented as subsystem that does things like DRM(I'm not sure if this would be possible either, but it could be).
I might be completely wrong here, but can someone sketch out how FHE can be used to make an unhackable consumer device?
I'm not sure I understand the question, but to me FHE is purely computational thing - only CPU and RAM are involved, and also operations include input and output data. To prevent the system from learning anything about the data, all operations are of kind
(RAM, encrypted output) = FHE(RAM, encrypted input)
so all data in RAM get there in the encrypted form in the first place. Thus the FHE system never see unencrypted data.
Coming back to an unhackable consumer device - if you measure a physical property, like temperature, or have a digital model of anything - you have to provide this data to FHE system only in the properly encrypted form. That encryption is on the consumer, not on FHE, as well as decryption of results of FHE operations. It's only the processing of data which FHE does.
What I hoped for is that FHE would usher in the era of more end-user control over the data, not less off it. That's because it would allow to decouple and isolate storage from compute, in such a way that I could invite company's code to process my data, encrypted by me, at the location of my choosing, and the code would have no way to exfiltrate the data. At the same time, I would have no way to get at the service company's software. I somehow never realized it would be easier for software providers to just skip the "my data at my location" part, and just force us to use their FHE software while also owning the data entered into it.
> Once one can do multiplication and addition all other operations can be bootstrapped from there so you can indeed do anything a Turing complete computer can do.
This is apparently iterated on many articles about FHE, but it seems false to me: to do Turing-complete stuff you also need comparisons, and the ability to change your flow depending on comparisons. But clearly you cannot do that with FHE, otherwise you could extract the encrypted content, one bit at a time.
My understanding is that an FHE computer can only execute a fixed net of additions and multiplications (or whatever operations they've got). So you can emulate an "if" clause by computing both branches and then selecting one of the two multiplying by 0 and 1 appropriately; you can do bounded "for" loops always executing the maximal number of times, but you can't do unbounded loops, therefore bye bye Turing completeness.
Of course there are a lot of interesting algorithms that can be executed without being Turing complete, but the general statement is false. Am I missing anything?
> That still doesn't address the parent's confusion (that I share) of how you get Turing-completeness just from addition and multiplication.
I wouldn't say arithmetic circuits are Turing complete since they can only perform bounded computations, but we could say that they're functionally complete. It is known that boolean AND and OR gates are functionally complete, and we can reduce them to multiplication and addition in any finite field:
x and y = x * y
x or y = ¬(¬x and ¬y) = 1 - (1 - x)(1 - y)Consider the following conventional code:
if (flag) {
a = b + c
} else {
a = b * c
}
a = flag * (b+c) + (1-flag) * b * c
It seems to me the only option is unrolling those loops. But that has a massive performance penalty. Because you need to always run through however deep you unrolled.
I'm not saying it is a practical solution to unroll a loop that might run a billion times.
This exposes the number of iterations needed to finish the computation. That could further be limited by underlying code rounding the iterations to mask the real count.
TLDR: either the run time is fixed or you leak some info via the run time.
In SNARK programming, we would usually decompose field elements into bits, then apply a binary comparison circuit. Binary decomposition can be done non-determinstically, by having the prover give the purported bits as "advice" inputs, then having the circuit accumulate those bits and check the sum.
I haven't done any FHE circuit programming, but I imagine that approach wouldn't work, since the circuit must be deterministic. I imagine any values that might need to be compared would just be encoded as binary from the start. (Or is there a better approach?)
Then again, it just occurred to me that perhaps fully homomorphic implies that F(0) = 0 and F(1) = 1, so a > b could become F(a - b) ρ 0, and you only need to determine beforehand if ρ is > or <.
If you want to build arbitrary functions like you've described, it reduces to the question of whether you can "unroll" the function, given its inputs[1], into a (stateless) circuit. But that would still IIUIC just get you primitive recursive functions (i.e. those where you can know the upper bound on the number of loop iterations for any loop before it starts), not the general recursive functions you need for Turing-completeness.
Anyone know how you pull off general recursive functions from just addition and multiplication?
[1] and in FHE you don't know the inputs either, which is another kink.
The primitive recursive functions cannot be expressed using circuits. Circuits by definition can only express polynomials, which have a much smaller growth rate than what primitive recursive functions are capable of.
[edit]
Actually, probably a better reason is that in primitive recursion, the running time can depend on the input. For a circuit, the running time is independent of the input.
That is probably what the researcher is referring to. You can encapsulate computation, but not in a single math equation.
https://en.wikipedia.org/wiki/Homomorphic_encryption#Fully_H...
If it's really just addition and multiplication, it's not FHE.
I found this link [1] which makes this distinction:
> Partially Homomorphic Encryption (PHE): In PHE scheme, only one type of mathematical operation is allowed on the encrypted message, i.e., either addition or multiplication operation, with unlimited number of times,
> Somewhat Homomorphic Encryption (SHE): In SHE, both addition and multiplication operation is allowed but with only a limited number of times.
> Fully Homomorphic Encryption (FHE): FHE allows a large number of different types of evaluation operations on the encrypted message with unlimited number of times.
And even then, multiplication is just repeated addition, so it still feels off to say it goes beyond partially homomorphic in the above schema. (Edit: actually, for arbitrary inputs, you can't reduce it like that, so ignore this para.)
In any case, original claim from the article that started this thread [2] is wrong.
[1] https://www.sciencedirect.com/topics/computer-science/fully-...
[2] "Since all mathematical and logical operations can be built from additive and multiplicative operations, "
Another way to look at it is, in homomorphic encryption you have the problem that in an operation both operands are encrypted. Therefore repeated addition based on one operand is not an option.
> Such a scheme allows one to compute arbitrary functions over encrypted data without the decryption key [- i.e. ...]
My understanding is, while FHE can not implement an algorithm to solve a problem of arbitrary size input, it can apply arbitrary computations to a limited size input.
Arbitrary computation is also, afaik, not well defined.
edit: After putting some thought into this, I feel like the idea is: Circuits can perform arbitrary computations on a limited size input, but not on an arbitrary size input. Loops are not a problem, as they are an implementation detail. Unbounded output is not possible on a touring machine that halts for all inputs of size s limited by some constant. There exists a circuit that would compute the same thing, as you can take the (binary encoded) results of the touring machine and just create a truth table from that, which describes a circuit. Circuits are interesting because they are usually limited in size.
Yes it is, it's Turing-completeness.
While this may be a sensible interpretation, and I am willing to believe it's used in that interpretation in some fields, I have a hard time actually finding a definition of that form.
I also have a problem with using it in this way: In circuits the size of the circuit limits your input size. But given a maximum size of the input, and no size limitations on the circuit, you can construct a circuit that produces the same result as a turing machine that halts. So you can compute whatever you want (i.e. arbitrary) but you are limited by the size of your current circuit.
(Completely unhelpful but always fun to look at for words: https://books.google.com/ngrams/graph?content=arbitrary+comp... )
Furthermore, it adds a huge constraint to programming: you can only implement loops with iterations bounded by a constant known at compile time. (And if you derive any of those constants from the inputs at the time you're compiling it for the FHE machine to execute, you've leaked information about said inputs.)
FHE is bounded-memory Turing complete, the same as every computer on the planet.
A specific circuit has a fixed running time, but it can do arbitrary computations in that runtime, including emulating a fixed number of steps of an arbitrary Turing machine.
Our physical computers also have limitations (particularly space) on what Turing machines they can simulate, however they are often called "Turing complete" in general parlance. Obviously a laptop though has limitations that are on completely different orders of magnitude though, and are much more efficient.
Many "surprisingly Turing complete"[1] systems have similar limitations, but the more interesting question is "can you use this system to simulate a bounded number of steps of a Universal Turing machine?" and the answer for those systems, and FHE is yes.
Result has no bit set = both terms equal Result's sign bit is set = second term bigger Result's sign bit isn't set = first term bigger
Multiplying by the result of comparisons (aka 0 and 1, as you state) is actually a common performance optimization. Does not work for everything, but when it works it works well.
result = if condition { a } else { b }
result = condition * a + (1 - condition) * bAlso unbounded loops can’t practically finish even on a Turing machine :)
FHE is equivalent to circuits, i.e., every circuit has a representation as a FHE. I feel like the idea is: Circuits can perform arbitrary computations on a limited size input, but not on an arbitrary size inputs. Loops are not a problem, as they are an implementation detail. Unbounded output is not possible on a touring machine that halts for all inputs of size s limited by some constant. There exists a circuit that would compute the same thing, as you can take the (binary encoded) results of the touring machine and just create a truth table from that, which describes a circuit. Circuits are interesting because they are usually limited in size.
So you compile your program into a circuit of a fixed size and can then compute solutions of this size. If you are interested in larger problems, you compile your program into a larger circuit. E.g., a function returing an 32bit integer and taking 20 32bit integers as parameters can be represented this way (without infinite loops, but those aren't covered by turing machines either), no matter the computation within that function.
edit: correction, obviously a circuit can not represent all partial functions, only functions (i.e., all inputs have an output).
And loops are not an implementation details. Bounded loop are, one might argue, an implementation detail, but unbounded loops are precisely _the_ problem: in general it is impossible, given an arbitrary Turing machine (or an arbitrary C, Python, whatever Turing-complete language program), to give an upper bound on the number of iterations its loops will require.
In hindsight it's kind of obvious: All functions computed by circuits must be a function an can not be a partial function, because a circuit can't output nothing.
The task is not that; instead we assume that we already have a table that correctly describes the TM's maps from bounded input to output when they terminate. His claim is that this table can be expressed as a function in addition and multiplication with the input as operands. To be more precise, with the input and constant numbers (arbitrarily choosable while designing the description of the function) as operands.
Incidentally,
> You can't even describe a Turing machine on one single input (using whatever operations you like)
is false, we can simply encode it as the encoded tuple of the TM and the input; this is a standard construct when we talk about simulating TMs with a UTM.
Ok, if the task is this then everything is very easy, I agree. I was commenting on a much harder task, i.e., converting a generic TM to a function adding and multiplying the inputs. That is something you can't do.
> is false, we can simply encode it as the encoded tuple of the TM and the input; this is a standard construct when we talk about simulating TMs with a UTM.
I don't see how that disproves my assertion. I was saying something different, which has to do with your (correct) first assertion: a TM cannot establish if another TM is going to terminate on a certain input.
It's important to be precise with language; said encoding is a description of a given TM on a particular input, since a map exists from it to the space of outputs union DOESNOTTERMINATE. Now, whether or not this map is a computable function is a different question.
> A key part of the proof was a mathematical definition of a computer and program, which became known as a Turing machine; the halting problem is undecidable over Turing machines.
It cannot be possible to “map” a Turing machine with a finite number of operations. Without true decision trees and loops, FHE isn’t Turing complete. At minimum, there needs to be a concept of a conditional jump—if X, jump to instruction Y.
You can unravel some programs into a finite set of instructions, but that doesn’t make FHE Turing complete.
Take the following code, for example:
function f(x):
while x == 1:
do nothing
return x
FHE can’t reuse circuitry. There’s no concept of, “based on the output, we now need to plug it back in and repeat.” Instead, it has to literally repeat that circuitry for every possible loop.
Again - the only reason you shouldn’t do that in homomorphic encryption is because this way you will leak run duration information.
That is to say? If X = 1 or X = 2 the processor did not appear to “do nothing” but, instead, performed an operation on an encrypted string that was constant time?
Forget Turing completeness for a second, that’s not actually what you want for a FHE style system. You want computational indistinguishability which can’t be achieved without side-channel resistance.
If you can think of something besides encoding a Turning machine's state as NN weights I am very interested. Perhaps encoding a quantum circuit somehow? A technically correct but intractable solution would be simulating the quantum state of every atom in a silicon circuit.
- If the program is meant to run forever, or as long as possible, then the system performing the computations can drive the loop. This might be useful for anytime algorithms (e.g. an AI/optimisation problem): e.g. "keep iterating this computation (unless my billing account runs out of credit), I might ask for the current state at some point in the future".
- Programs which eventually halt could be checked by the key holder: the result gets decrypted, and if it isn't in the 'halt' state then it's sent back for another 'step'. In practice this could be made more efficient by e.g. making the computation idempotent, so it can be iterated many times without having to ask for confirmation every time; by having the encrypted computation perform many iterations, so each 'step' does more work; etc. If the job is kept on the encrypted system, with the key holder sending it step/stop instructions, that leaks details of the computation (i.e. an upper-bound on how many steps it takes). If we're willing to round-trip the data instead, then the key-holder can re-encrypt it each time (and jitter its timings), so the server couldn't tell the difference between stepping the same job and computing multiple jobs. This could be further obfuscated by throwing our jobs into a pool of others, e.g. on a shared proxy.
This model of having some external entity "driving" a computation's loop appears in a few other places too:
- Smart contracts, like Ethereum, give programs "fuel" that decreases with each step, and calling another program requires us to give it some of our fuel.
- Optimisation algorithms can also use "fuel" to avoid infinite loops. Some compilers use this to avoid transformations getting stuck in a cycle (rewriting the code between one form and another).
- Total (functional) programming languages, like Agda and Coq, don't allow general recursion; yet they do allow co-recursion. This lets us wrap each recursive call (i.e. step) in a constructor, then we can "drive" the program by having an external program unwrap these constructors (AKA a main loop).
- Coq's Mtac language lets us use general recursion in our proofs, but the results get wrapped up (just like the co-recursive example above). The compiler will run these proofs to completion: if they don't halt then neither does the compiler.
- CSS can be "driven" by user clicks, which together become Turing complete: https://notlaura.com/is-css-turing-complete
Practically this might still be an acceptable way to tackle the problem. I mean, "practically" as much as FHE itself is.
Now you can run the FHE step for as many times as the algorithm requires, giving you a FHE-VM that can execute any WebAssembly program from your favorite Turing complete programming language.
The limitations are that you need to define a bounded machine state, which technically breaks the Turing completeness. In practice this is no different from your laptop having a finite amount of memory which disqualifies it as a Turing machine. Real Turing machines don't exist.
The other limitation is that the FHE executor can now see the total run time of the algorithm, which was secret before. This is similar to a timing side channel and similar mitigations apply.
As others have pointed out, if you have a concrete algorithm you can do something much simpler than implement a VM. The Collatz sequence is good toy example of an algorithm with unknown loop bounds. You would make a FHE circuit that iterates a single step using the same overall design.
Is it a stretch to say that "1: perform this list of multiplications and additions. 2: GOTO 1" cannot be called a FHE system?
A UTM is an unbounded tape T of encrypted bits, an encrypted state S, a circuit U(S, B) = (S', B', V') representing the state machine of the TM with V' as an output to control the next step, and the circuit for D_O(X). After each evaluation of U the state S is replaced by S', the bit at the current position on the tape is replaced with B', and if V = D_O(V') is 0, move the position on the tape left, if it's 1 move right, and if it's 2 then halt.
A bounded-length Turing Machine can be represented as a finite state machine (with the computing power of a standard physical computer) without leaking any information about changes to the tape by (T', S', V') = FSM(T, S) where the entire tape T is replaced by the output of the circuit at each step and D_O(V') is 1 for continue or 0 for halt.
I don't like the name "termination oracle", it sound too much like "halting oracle" which is not what is going on here. All we do is add an outer while-loop, a simple algorithmic transformation. I wouldn't even consider that an oracle.
(ANDs and XORs are just multiplication and addition over bits, and we build comparisons out of these all the time.)
Re: the ability to do control flow, you can implement your Turing machine automaton as a circuit easily, and can then evaluate that using FHE
The database is a key value store prepopulated with the english names of countries and their capital cities from the continent of Europe. Selecting the country will perform a search of the matching capital. On a 2019 Macbook Pro laptop, the example searches take under 80 seconds.
https://news.ycombinator.com/item?id=23435305
And today this article claims only a 40x compute cost for "machine learning"?
What is the cause of the disparity?
That's not to say that a badly-designed usage of homomorphic computation can't introduce a timing channel, though. If there's a point in time where the result is handed back to the client, they inspect it, and then conditionally send more computations, you might be able to infer something with either the client's timing or if they happened to send back more computations or not. However, that assumes that we'd be able to trace multiple API requests associated with the same data set (as opposed to unrelated computations), and that we know enough about the computations we're being told to do to infer a timing channel from them. That's why I use the qualifying term "badly-designed", which in practice will probably be most uses of this technology.
I don’t think it’s possible for a circuit to operate over a large set quickly and use a fully homomorphic pure software design.
Are those multiplicative factors specific to machine learning tasks, or is it the same for general purpose computation?
In other words, is there something about the structure of machine learning tasks which makes them more suited for FHE than other computing tasks?
It will also allow organizations to train models collaboratively in a privacy preserving way, which if you think about it has lot of consequences.
If you want to share data on common customers, without revealing who your unique customers are, you need set intersection.
Yes, FHE is not (currently) good at general-purpose computing. Complex conditional logic for example is a non-starter because every branch has to be evaluated. But tensor multiplication is well supported with existing FHE schemes, and many kinds of machine learning tasks consist of non-conditional tensor multiplications.
Is overcoming this limitation of FHE anywhere on the horizon?
I admit understanding this paper is a bit beyond me. But, does their construction evaluate Turing machine conditionals by evaluating both branches? If it did, how could the running time be "dependent on the running time of M on input x as opposed to the worst-case runtime of M"? It seems to me that having to evaluate every branch irrespective of the input would result in the running-time always being M's worst case, not varying runtime depending on the input.
There are some circuit compilers that try to do optimizations like that automatically, like xJsnark, though it's not meant for FHE.
To quote his TLDR:
> TLDR Huge polynomials are what are operated on instead of plaintext values by hiding the real data in the polynomials with intentional noise to make it infeasible to extract the real data without the decryption key that knows how to remove it. All operators are bootstrapped from addition and multiplication and elegant modulus trickery. Noise is managed at each operation because the noise compounds with every logic operation you do. The result of an operation chain or circuit be it one operation or infinitely many, therefore, has some noise but can be decrypted by the person with the encryption key. The decryption effectively drops all the noise and hones in on the bits that matter. The person doing the computation is doing a lot of adds and multiplies on big polynomials so they cant understand what you are really trying to do.
Is that true? I would like to know more on what kind of garanties SEV gives / how it works high level, any resources you can recommend? I assume that at least when the VM is being launched, the sysadmin can mess up with the VM?
Which both are probably untrue assumptions :-)
We've banged out some stuff with HElib, and some other interesting implementations, but are just beginning.
And we're hiring for both backend and data science positions. :) jobs@theembassies.com
MPC introduces a trust assumption. MPC is only private if some threshold of the multiple parties are honest and destroy their secrets. Though often this threshold is just one, efficient MPC often only has 3 participants total.
FHE gives you a better security model than either of these, as it neither relies on physics for safety nor needs to assume any level of honesty from the person running the computation.
As the comments in the article state, it's actually all done with operations on polynomials with encrypted coefficients. As + and x can be done on polynomials, it all works out.
The maths behind it is of course much more complicated.
As for a simple maths analogy, consider adding 1 + 2.
I'll encrypt your values by multiplying by 3 mod 7. So encrypt(1) = 3x1 mod 7 = 3 mod 7 and encrypt(2) = 3*2 mod 7 = 6 mod 7. Only the encrypted values are sent, along with the operations I want to perform on the values.
Now this scheme is homomorphic, as I can just add the encrypted values, encrypt(1) + encrypt(2) = 3 + 6 mod 7 = 2 mod 7. That is the only computation that would be done before sending back the result.
To decrypt it, I would have to divide by 2 mod 7 by 3, which gives me 3 (you can easily check that encrypt(3) = 2 mod 7). And indeed 1 + 2 = 3. So the decrypted answer is correct.
Of course this scheme is too easy to crack. The FHE scheme is not.
i think you meant divide by 3 mod 7:
9 / 3 mod 7 = 3
Too bad Moore's Law is dead, otherwise it would have been possible to run everything we run now in 10-12 years using Fully Homomorphic Encryption for the same cost!
If we keep up the trend (big if) this is actually quite promising
Rough description: CPU have secure memory which contains a private key. Also CPU have certificate with corresponding public key. That certificate is signed by Intel.
Hosting provider publishes an API which allows remote user to communicate with that secure CPU, basically just transmitting encrypted stream to and from CPU.
When you're starting your communication, you establish an encrypted link between your machine and target CPU, located in a data center. You can check authenticity of that CPU by checking certificate signature. Then you're sending any code you would like to execute (encrypted by session key). CPU executes that code. It encrypts RAM in process, so it's not possible to read its contents. And sends back some information (again, encrypted) which you're interested in.
So you have computing resources which are protected from anyone except very few who could extract private key from secure chip. I think that this kind of protection should be enough for many uses. And it would not compromise on performance. The only real world issue would be side channel attacks.
> protected from anyone except very few who could extract private key from secure chip
The way I understand chip manufacturing it would be hard to diffuse a separate key into each chip. This means it'd only take one of those very few people to extract and leak the key (or cut out the middleman and leak it from inside AMD) to break it for everyone.
> The only real world issue would be side channel attacks.
This is probably a much bigger problem in practice. Spectre & related attacks have been effective against Intel SGX[2], another "trusted environment" inside a larger system.
[1]: https://developer.amd.com/sev/ [2]: https://arstechnica.com/gadgets/2018/08/intels-sgx-blown-wid...
…and Intel. This has obvious problems in who the root of trust should be, as well as putting all the eggs in the same basket.
Also, what you propose is I think equivalent to the SEV technology mentioned in the article.