some small changes to make mpyc compatible with oblif #25
Conversation
Codecov Report
@@ Coverage Diff @@
## master #25 +/- ##
==========================================
- Coverage 89.75% 89.72% -0.04%
==========================================
Files 13 13
Lines 4324 4330 +6
==========================================
+ Hits 3881 3885 +4
- Misses 443 445 +2
Continue to review full report at Codecov.
|
|
Hi Meilof! I've made some minor changes to make things more consistent with MPyC. Defining The secobj.if_else(x, y) idiom was on the roadmap so that's certainly fine too. There will be more instance methods like if_else() for SecureObject to hide the use of the runtime. E.g., for runtime.random_bits() etc. The shortcut for the "x is y" case in if_else() looks like it should work in general, I can imagine that it may give you a much better efficiency for oblif. Or do you need it also for another reason? |
|
Yes, I think defining __deepcopy__ this way makes sense as long as
SecureObject does not have in-place operators such as __iadd__. Some other
Python constructs also behave like this, e.g.:
>> deepcopy(a:=tuple([1,2]))==a
True
>> deepcopy(a:=tuple([1,object()]))==a
False
The "x is y" shortcut indeed helps for efficiency. In particular, it is
important to help prevent objects being "promoted" to oblivious values for
as long as possible. For example, consider this example:
a=5
if guard:
b=a
Because a is accessed in the "if", this will trigger guard.if_else(a,
deepcopy(a)) (this is needed because if a is not an immutable object, then
the code in the if statement needs to act on a copy of a). The combination
of letting deepcopy return the object itself, and having if_else detect
that the object is independent from the guard, means that a is still an int
after the loop and not a SecureObject.
…On Sun, May 9, 2021 at 6:26 PM Berry Schoenmakers ***@***.***> wrote:
Hi Meilof!
The changes you propose are very reasonable, certainly to make the use of
oblif near to effortless.
I've made some minor changes to make things more consistent with MPyC.
Defining *deepcopy* for SecureObject does not seem to interfere with
anything (yet). I've also tested things with all the MPyC demos.
The secobj.if_else(x, y) idiom was on the roadmap so that's certainly fine
too. There will be more instance methods like if_else() for SecureObject to
hide the use of the runtime. E.g., for runtime.random_bits() etc.
The shortcut for the "x is y" case in if_else() looks like it should work
in general, I can imagine that it may give you a much better efficiency for
oblif. Or do you need it also for another reason?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#25 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACAJUU6AVSZU6DNAFKC7X3LTM2ZS5ANCNFSM44MZF72Q>
.
--
Meilof
-- ***@***.***
|
|
Yeah, currently there are no in-place methods for SecureObject. I've experimented a bit with it though, making So, your PR is now merged, thx a lot! |
These small changes make it possible to use mpyc together with oblif: