Re: Non-source routing (was "failures during the preparation phase")

Thank you Pedro!

High hopes for this approach.
On Mar 25, 2016 7:30 PM, "Pedro Moreno Sanchez" <pmorenos@purdue.edu> wrote:

>  Thank you for your interest!
>
> Given the interest, I have uploaded the current draft of ZeroPay [1], the
> other system on which we are currently working. As I said in my previous
> email, it shows that it is possible to enforce strong privacy guarantees
> (as we did with PrivPay) in a distributed setting, where each node in the
> network only need to know its neighbors (e.g., its own credit links).
>
> On 3/25/16 6:07 PM, Jehan Tremback wrote:
>
> Do landmark nodes have a special role in the network? Must someone
> "appoint" a landmark node, or can any node step in and fill this role at
> any time?
>
> In principle any node in the network could play the role of landmark since
> a landmark is just an intermediate node in the path from the sender to the
> receiver. However, I believe that in practice, nodes with high liquidity
> are more likely to play the role of landmarks since many payments are
> routed through them. For example, banks would be the natural candidate to
> server as landmarks in a payment system. In Ripple, most nodes have links
> to a few highly connected nodes (Ripple gateways).
>
> Where is the "Universe Creator" located?
>
> In PrivPay, the universe creator is a functionality that is carried out at
> the server side. In a bit more detail, the universe creator is executed in
> a secure processor (e.g., the 4765 cryptographic co-processor by IBM [2])
> installed in the server. This processor is considered secure in the sense
> that it is not possible to spy on the computations performed inside of it
> or read its (small) internal memory. There are other works that have
> successfully used such a trusted platform to solve privacy issues on other
> scenarios [3, 4].
>
> Am I correct in inferring that this is a system designed to be run on a
> centralized node that knows about the entire network topology?
>
> The complete credit network is stored on the server in an encrypted
> fashion. The key for such encryption is stored in the secure processor.
> Thus, the server does not have access to any information about the network
> (and thus it does not know the network topology) since it is not possible
> to extract the key from the secure processor.
>
> In such setting, it is still challenging to perform changes over the
> encrypted credit network to carry out the payments. The naive solution of
> decrypting the complete credit network within the secure processor's memory
> does not work because this memory is small. Another possibility would be to
> sequentially decrypt the necessary blocks from the encrypted credit
> network, perform the changes and encrypt them back. This, however, leaks
> information about the access pattern and this leak can be used by the
> untrusted server to figure out who is the receiver of a transaction or the
> transacted value. We solve this challenging problem in PrivPay by designing
> algorithms that obliviously access the encrypted data (i.e., hiding the
> access patterns).
>
> Btw, I have seen in a previous email in this mailing list that you are
> working on a payment routing protocol (Reactive Payment Routing). I think
> that it would be interesting to compare this approach with our ongoing work
> ZeroPay [1]. It might be worth it to see what we can extract from both
> approaches to handle pathfinding and privacy issues on ILP.
>
> -Pedro
>
> [1] Kate, A., Maffei, M., Malavolta, G., Moreno-Sanchez, P., ZeroPay: A
> Distributed Architecture for Enforcing Privacy in Credit Networks. Work in
> progress.
> http://crypsys.mmci.uni-saarland.de/projects/DecentralizedPrivPay/draft-paper.pdf
> [2] IBM Systems, "IBM Systems cryptographic hardware products,"
> http://www-03.ibm.com/security/cryptocards/
> [3] Backes, M., Kate, A., Maffei, M., Pecina, K., ObliviAd: Provably
> Secure and Practical Online Behavioral Advertising. In IEEE S&P 2012.
> http://sps.cs.uni-saarland.de/publications/obliviad.pdf
> [4] Bajaj, S., Sion, R., TrustedDB: A Trusted Hardware Based Outsourced
> Database Engine. In PVLDB 2011.
>
>
> -Jehan
>
> On Fri, Mar 25, 2016 at 2:36 PM, Daniel Bateman <7daniel77@gmail.com>
> wrote:
>
>> Interesting!
>>
>> Can Interledger function with a system like PrivPay?
>> On Mar 25, 2016 2:32 PM, "Pedro Moreno Sanchez" <pmorenos@purdue.edu>
>> wrote:
>>
>>> Hello,
>>>
>>> my name is Pedro Moreno-Sanchez and I am a PhD student at the computer
>>> science department at Purdue. My current research focuses on security and
>>> privacy issues on credit networks. Moreover, I will be doing an internship
>>> at Ripple this summer. Thus, I hope I can use this opportunity to meet some
>>> of you there and discuss the interesting things that are going on in this
>>> group.
>>>
>>> I would like to bring to your attention a (non-source) routing approach
>>> called landmark routing [1]. In a nutshell, this approach calculates a path
>>> between a sender and a receiver through an intermediary node called
>>> landmark. The idea behind this approach is to calculate the shortest path
>>> (i.e., Breadth-First Search) from the landmark to every other node and vice
>>> versa, from every node to the landmark. Then, a payment path from sender to
>>> receiver can be reconstructed as sender -->other nodes --> landmark -->
>>> other nodes ---> receiver. Vismanath et al.[2] have shown that landmark
>>> routing performs much faster than other routing approaches (e.g., using
>>> max-flow) in credit networks.
>>>
>>> Given the similarities between a credit network and the ILP settings, it
>>> might be worth it discussing this approach here. Moreover, as part of my
>>> research, I have studied whether it is possible to use landmark routing to
>>> build a credit network with privacy preserving payments. This is
>>> challenging not only because of possible privacy leaks while calculating
>>> payment paths but also due to privacy leaks during the calculation of the
>>> available credit in a path.
>>>
>>> To overcome these challenges, we designed a system called PrivPay [3], a
>>> credit network system that uses a privacy-enhanced version of landmark
>>> routing to perform privacy preserving payments. More recently, we have
>>> designed a privacy-preserving credit network system with which we show that
>>> it is possible to enforce strong privacy guarantees as we did with PrivPay
>>> but in a distributed setting, where each node in the network only knows its
>>> neighbors (e.g., its own credit links). Although this last work is not
>>> published yet, I would be glad to share and discuss it with you if you are
>>> interested.
>>>
>>> I would be interested on discussing my experiences during my research
>>> regarding not only routing mechanisms on credit networks, but also privacy
>>> preserving payments. I believe that privacy is an interesting and important
>>> aspect that might be worth considering on the ongoing discussions about ILP.
>>>
>>> --
>>> [1] P. F. Tsuchiya, “The Landmark Hierarchy: A New Hierarchy for
>>> Routing in Very Large Networks,” SIGCOMM Comput. Commun. Rev., vol. 18,
>>> no. 4, pp. 35–42, Aug. 1988.
>>> [2] B. Viswanath, M. Mondal, K. P. Gummadi, A. Mislove, and A. Post,
>>> “Canal: Scaling Social Network-based Sybil Tolerance Schemes,” in EuroSys
>>> ’12, 2012, pp. 309–322.
>>> [3] Moreno-Sanchez, P., Kate, A., Maffei, M., and Pecina, K. Privacy
>>> preserving payments in credit networks: Enabling trust with privacy in
>>> online marketplaces. In NDSS(2015).
>>> http://www.internetsociety.org/doc/privacy-preserving-payments-credit-networks-enabling-trust-privacy-online-marketplaces
>>>
>>
>
>