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

 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
> <mailto: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 <mailto: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
>
>