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

I think the sort of landmark routing you describe could be very useful if
the topology of the network was such that a large proportion of the
available liquidity was concentrated in a single node, which seems likely,
at least early on. The way you have described it, however, it seems more
like an alternative pathfinding algorithm than an alternative routing
system, since one could theoretically use this method to efficiently
compute a route at the sender, and then you're using source routing, or
efficiently compute a route at each step, and then you're using dynamic
routing. Either way, I don't think this would require a protocol change,
since it would just be a choice of algorithm on behalf of the
sender/connector in question. I could be completely wrong and
misinterpreting your proposal, however.

On Fri, Mar 25, 2016 at 7:44 PM, Daniel Bateman <7daniel77@gmail.com> wrote:

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


-- 
“The true logic of this world is in the calculus of probabilities.” – James
Clerk Maxwell