I hadn't seen it, but this shouldn't be too surprising? Like @smith1517 said, the primitive itself is safe. Implementing this type of complex software can introduce serious security problems though if done wrong or certain edge cases aren't accounted for.
One of the examples given in the paper is about data encoding of integers leaking information if there are many-to-one parties involved. Another encoder they used (within this given library, SEAL) doesn't have information leakage and could be used to circumvent the issue above.
If you have complex algorithms and software, bugs will exist. If you wire together complex libraries that work on certain assumptions, test if they still hold up and guarantee the security boundaries you initially setup.
It can always happen that a specific implementation of software has a vulnerability (like Dusks Plonk had), what is important is how easy is it to fix that vulnerability? I guess one of the main criticisms of TEEs is that, due to depending on third party hardware and libraries, mitigation or patches have a much longer lead time (on average) than if you have an issue in your own code base.
I hadn't seen it, but this shouldn't be too surprising? Like @smith1517 said, the primitive itself is safe. Implementing this type of complex software can introduce serious security problems though if done wrong or certain edge cases aren't accounted for. One of the examples given in the paper is about data encoding of integers leaking information if there are many-to-one parties involved. Another encoder they used (within this given library, SEAL) doesn't have information leakage and could be used to circumvent the issue above. If you have complex algorithms and software, bugs will exist. If you wire together complex libraries that work on certain assumptions, test if they still hold up and guarantee the security boundaries you initially setup. It can always happen that a specific implementation of software has a vulnerability (like Dusks Plonk had), what is important is how easy is it to fix that vulnerability? I guess one of the main criticisms of TEEs is that, due to depending on third party hardware and libraries, mitigation or patches have a much longer lead time (on average) than if you have an issue in your own code base.