Trusted third party

About: Trusted third party is a research topic. Over the lifetime, 2919 publications have been published within this topic receiving 60935 citations.

When Can a Distributed Ledger Replace a Trusted Third Party

Abstract: The functionality that distributed ledger technology provides, i.e., an immutable and fraud-resistant registry with validation and verification mechanisms, has traditionally been implemented with a trusted third party. Due to the distributed nature of ledger technology, there is a strong recent trend towards using ledgers to implement novel decentralized applications for a wide range of use cases, e.g., in the financial sector and sharing economy. While there can be several arguments for the use of a ledger, the key question is whether it can fully replace any single trusted party in the system as otherwise a (potentially simpler)solution can be built around the trusted party. In this paper, we introduce an abstract view on ledger use cases and present two fundamental criteria that must be met for any use case to be implemented using a ledger-based approach without having to rely on any particular party in the system. Moreover, we evaluate several ledger use cases that have recently received considerable attention according to these criteria, revealing that often participants need to trust each other despite using a distributed ledger. Consequently, the potential of using a ledger as a replacement for a trusted party is limited for these use cases.

Method for notarizing receipt of electronic communications and enabling electronic registered mail; method for verifying identity of account party

Abstract: A notarization method is disclosed whereby two parties can transmit and exchange electronic data without sharing either the data or any proprietary security information with third parties, and whereby the receiving party cannot surreptitiously examine the data without creating a logged record. In a preferred embodiment, the sending party uses an encryption algorithm to encrypt the data package, generating an encrypted copy of the data and a session key that can be used to retrieve the plaintext copy of that data package. The session key is split into two or more discrete subkeys, some or all of which are required to reconstruct the session key, and none of which alone will compromise the other subkeys or the data package. Using secure transport methods, the encrypted data packet and one or more subkeys are delivered to the intended recipient. The remaining subkeys are either retained by the sending party or delivered to a trusted third party using secure transport methods. Using secure and verifiable transport methods, the recipient retrieves the remaining subkeys. This retrieval is logged and an electronic receipt is created documenting the time of retrieval and the identity of the retriever. Once the recipient has sufficient subkeys, it reconstructs the session key and decrypts the data package. The result is similar to a postal system of registered mail, using encryption to replace the security of a human being requiring a physical signature. In an alternate configuration, the system is used to verify the identity of one party for use in applications such as allowing anonymous electronic cash transactions.

Privacy-Preserving Methods for Feature Engineering Using Blockchain: Review, Evaluation, and Proof of Concept

Abstract: Background: The protection of private data is a key responsibility for research studies that collect identifiable information from study participants. Limiting the scope of data collection and preventing secondary use of the data are effective strategies for managing these risks. An ideal framework for data collection would incorporate feature engineering, a process where secondary features are derived from sensitive raw data in a secure environment without a trusted third party. Objective: This study aimed to compare current approaches based on how they maintain data privacy and the practicality of their implementations. These approaches include traditional approaches that rely on trusted third parties, and cryptographic, secure hardware, and blockchain-based techniques. Methods: A set of properties were defined for evaluating each approach. A qualitative comparison was presented based on these properties. The evaluation of each approach was framed with a use case of sharing geolocation data for biomedical research. Results: We found that approaches that rely on a trusted third party for preserving participant privacy do not provide sufficiently strong guarantees that sensitive data will not be exposed in modern data ecosystems. Cryptographic techniques incorporate strong privacy-preserving paradigms but are appropriate only for select use cases or are currently limited because of computational complexity. Blockchain smart contracts alone are insufficient to provide data privacy because transactional data are public. Trusted execution environments (TEEs) may have hardware vulnerabilities and lack visibility into how data are processed. Hybrid approaches combining blockchain and cryptographic techniques or blockchain and TEEs provide promising frameworks for privacy preservation. For reference, we provide a software implementation where users can privately share features of their geolocation data using the hybrid approach combining blockchain with TEEs as a supplement. Conclusions: Blockchain technology and smart contracts enable the development of new privacy-preserving feature engineering methods by obviating dependence on trusted parties and providing immutable, auditable data processing workflows. The overlap between blockchain and cryptographic techniques or blockchain and secure hardware technologies are promising fields for addressing important data privacy needs. Hybrid blockchain and TEE frameworks currently provide practical tools for implementing experimental privacy-preserving applications.

Matching and assisting a buyer and a vendor from an inquiry, through a proposal, and to an order

Abstract: There is provided a computer-implemented method for enabling a host to facilitate a transaction between a first party and a second party. The method comprises the steps of: (a) receiving a communication from the first party; (b) querying a database based on the communication and obtaining a result that indicates the second party for engagement in the transaction; (c) sending a communication to the second party inviting the second party to correspond with the first party; (d) receiving a correspondence from the second party; and (e) presenting to the first party the correspondence from the second party.

One-Time Tables for Two-Party Computation

Abstract: In two-party secure computation, a pair of mutually-distrusting and potentially malicious parties attempt to evaluate a function f(x, y) of private inputs x and y, held respectively by each, without revealing anything but f(x, y) and without involving a trusted third party. This goal has been achieved with varying degrees of generality and effciency using a variety of primitives, including combined oblivious transfer (OT) [GMW87], abstract oblivious transfer [K88], and committed oblivious transfer [CTG95]. This work introduces the concept of a two-party one-time table (OTT), a novel primitive that is theoretically equivalent to precomputed OT. The OTT is tailored to support field computations rather than single-bit logical operations, thereby streamlining higher-level computations, particularly where information-theoretic security is demanded. The two-party one-time table is also motivated by the ease with which it can be constructed using simple resources provided by one or more partly-trusted external servers. This commodity-based approach strengthens overall security by ensuring that information flows strictly from servers to Alice and Bob, removing the need to trust third parties with the sensitive data itself.