|
|||||||||
| PREV NEXT | FRAMES NO FRAMES | ||||||||
See:
Description
| Packages | |
|---|---|
| net.jcip.annotations | Class, field, and method level annotations for describing thread-safety policies. |
| pygar.accounting | Classes that specify the price model for matching data and the exchange of real or virtual funds when encrypted data are shared as an outcome of a blind encrypted data matching session. |
| pygar.business_logic | Classes that specify the business logic of a BEDM application. |
| pygar.communication | The component responsible for communication between entities in the distributed system. |
| pygar.configuration | Classes that determine the configuration for running an application. |
| pygar.cryptography | This package provides facades and interfaces to cryptographic functions used in Pygar software. |
| pygar.demo0G | This package contains software for Demonstration 0 as implemented over the JavaEE server called Glassfish. |
| pygar.demo0P | This package contains software that implements Demonstration 0. |
| pygar.documents | This package defines the formats of documents exchanged during the operation of the system and supports the interpretation of their XML contents. |
| pygar.identity_authority | This package implements the system component responsible for identities as represented via public key encryption. |
| pygar.MessageServer | This package implements a message forwarding service that various network entities can use to exchange messages. |
| pygar.state | This package provides a general utility for implementing state machines whose transitions are driven by the arrival of data messages. |
| pygar.zoneable | In a highly secure installation of the software, the software should be split into applications running in several security zones. |
The Pygar Project aims to develop and deploy software and infrastructure for Blind Encrypted Data Matching or BEDM.
See Pygar Project Blog.This project is an ongoing effort that aims at progressive enhancement of the security features and refinement of the functional capabilities. At any time, there are points where additional development is justifiable. Some of these points are mentioned in Pygar's Skeleton Closet
Blind Encrypted Data Matching is a new method for negotiating an agreement when both sides are hiding all their information. The negotiation is conducted by a blind broker who is unable to read the hidden information. In the end, the two parties reach an agreement on a contract or the sharing of secret data without revealing any unnecessary information from their positions of secrecy. The broker is kept in the dark throughout.
BEDM is useful in situations were the parties are at great risk. They can't trust each other and they can't trust a third party negotiator. BEDM uses a middleman, but the middleman never sees anything that isn't encrypted. Nevertheless, the middleman/broker can identify links between encrypted statements that are made by the various parties. If there are linked statements, the parties know that they have an opportunity for a mutually-beneficial, highly limited, cooperative transaction. The parties can pursue that opportunity without revealing any information beyond the matching statements found during the encrypted data-matching operation. The middleman never learns what is involved.
The Pygar code is a copyrighted creative work that is made available for use under the Pygar Public License. The code is available under license so that the software community can view the core software algorithms and test, improve and validate the security features. See the Pygar Public License.
Remarks on the Software Packages
The Pygar software system comprises applications for a match-maker service that offers Blind Encrypted Data Matching or BEDM as well as applications for the clients of that service. The client applications help a client prepare encrypted data for matching, designate their match partners, and participate in matching sessions with the BEDM match-maker service. All applications are stored in packages in the software source directory.
Software that is shared between applications is also stored in packages and these packages are organized by software function.
Finally, any secure installation of this software must divide the software into security zones. The zones are created at the installation site by physical separation of computers, network firewalls, and other standard provisions. The Pygar software system designates packages by software zones but that by itself is merely installation information - not an assurance of security. To be secure, the software must be segregated by security zone when it is installed. For example, the client software to encrypt sensitive information is located in the most secure zone and widely separated from the client software that transfers encrypted documents to external sites. Packages that communicate over the internet should not be installed in the most secure layer and the designation of the packages by zone facilitates the implementation of this rule.
All of the packages are documented in the hypertext document that you are reading now with ancillary explanation referenced here by URL. The primary programming language for the project is Java SE 6.0.
The Pygar system obviously has different software releases for client and server. In addition, it may provide a different software release for each security zone at the local site. Certain features of the software system are provided as a support for generating a variety of releases. These features are noted in the software-source context where they appear. Here are a few reasons why a variety of releases are essential:
Please see the discussion on the subject
RestrictedImport
This section provides comments that apply to all the security zone packages and attempt to clarify how they are used together.
|
|||||||||
| PREV NEXT | FRAMES NO FRAMES | ||||||||