Skip to content

Cryptonomica White Paper

Jump to bottom Edit New page
Viktor Ageyev edited this page Mar 7, 2018 · 11 revisions

The global database of verified identities with service for signing electronic documents and online dispute resolution

www.cryptonomica.net

Table of Contents

How a digital signature works. Some technical details.

The digital signature is intended to identify the person signed an electronic document (file), this is a substitute for a handwritten signature on the document. Digital signature can be used for signing any document in electronic form. A digital signature is used to confirm the authorship of the document, and to verify that the document was not changed after it was signed. The same document can be signed by several digital signatures (for example, when signing contracts)

A reliable (both in the technical and the legal sense) system of digital signature is a prerequisite for the global transition from paper to electronic documents. Now people and organizations are storing paper documents in huge, and making mass mailings, and even fly to the meeting to sign documents, just because in many cases "a document with the signature" is required (and such a document is often paper with a flourishes, the authorship of which in most cases actually can not be really verified even by an expert).

The transition to electronic documents brings a lot of advantages, and allows to economize a lot of time and money. This facilitates storage of documents (instead of rooms, cabinets and shelves - one disk or storage "in the cloud"), processing and systematization of documents (for electronic documents instant search, tagging, cataloging are possible), transfer of documents (e-mail works much faster then even DHL), document archiving (electronic documents can be easily copied and stored in multiple places).

To use digital signatures efficiently it is necessary to understand how digital signature is designed.

A digital signature is a simply set of characters that can be attached to the text, like this:

----- BEGIN PGP SIGNED MESSAGE -----
Hash: SHA1

This is a digitally signed text .

----- BEGIN PGP SIGNATURE -----
Version: PGPfreeware 5.5.3i for non-commercial use
iQA/AwUBNjbvJnWapzcuIECXEQL8xgCg4MoNkkDMbkKsH3751ykbSqaVXUkAoJjR
crQAiyxewLPQJEdUS1lUF99u = 3Jsi
----- END PGP SIGNATURE -----

or in a separate file that accompanies the signed text, for example:

scanneddocument.jpg - signed file
scanneddocument.jpg.sig - signature

in the latter case it is possible not only to sign the text, but any file, for example, a scanned image or program.

A digital signature is created and verified by using a pair of corresponding keys: the private (secret) key and the public (open) key.

The key is also a set of characters.

The signature is generated by a known algorithm (usually RSA - the Rivest-Shamir-Adleman cryptosystem), in which the input is the private key and character set to be signed.

algorithm (the text to be signed, the secret key) = digital signature

A digital signature can be checked (verified) using the public key:

algorithm (the digital signature, the signed text, the public key) =
true/false

(i.e. whether the signature was created using private key from the same pair to which the public key belongs)

If in the signed file or text even one character (even a space or a comma) was changed, the test shows that the signature does not match the text.

Thus a digital signature uses a pair of keys: public and private, and signature generated using a secret key can be verified using public key.

Public key usually is represented in 'key certificate' which contains:

  • The first and last name of the key owner

  • E-mail of the key owner

  • Optional comment

  • Cryptographic key itself

Public key certificate usually contains also signature made by corresponding private key.

Also, this key pair can be used to encrypt messages and files. In such case, the sender uses the recipient's public key for encryption, and the restoration of the original text is only possible with the help of the associated private key (which is owned by the recipient only)

This technique is known as "public-key cryptography" or "asymmetric cryptography" ("asymmetric" because one key is open and another one is secret). Now public-key cryptography is used in most cases when encryption and/or signing the data transmitted over the network is necessary.

The most convenient and most commonly used standard for signing and encrypting documents and messages is OpenPGP (Pretty Good Privacy). Standard for OpenPGP is defined in RFC 4880 Currently, there are a large number of programs and libraries for this standard, from simple and convenient for the average user free open source programs such as Enigmail, to commercial enterprise products as Symantec Encryption Family. It is worth to mention GnuPG - a complete and free implementation of the OpenPGP standard, also known as GPG.

OpenPGP key ('key certificate') looks like this (it is an RSA 2048-bit key used by default in GnuPG) :

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.22 (GNU/Linux)

mQENBFTk0f0BCADDXWjTOt/q4fZqAtHb9Sb2XFMuu7yvDWOLm29s1GtbnTToe4S2
GXPiv4DI1Q+AKPUplLyBRGmQSCmaIAlBfbeO5lKrgPxtR3aeL2UVx8JaY7mv2K1a
btB+QkEFbrypqkJGF4vsSLPYPqRCyTZiFFuHKneCy77R2zage1MgEWe8mau4afUb
gYji/GmMALU4DaUlkc4le7goTUdIcti8sPjikj8aSn8tEvvW6/foI4rpFSxuyekT
cx0evkaV43hLty+iICl0BZDNXzZFdccnyAs9FONrtIaruk0FLDjuq5DqBQv9nPMg
XDsN20ZL1jvMf+yKkp/r+XW5A8WOK8zAHT47ABEBAAG0KlZpa3RvciBBZ2V5ZXYg
KHRlc3QgMDEpIDxhZ2V5ZXZAZ21haWwuY29tPokBOAQTAQIAIgUCVOTR/QIbAwYL
CQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQKz4p3gtPmhmdTwf+J49zXROgX1+c
SLfo0ALdtwRj+y3WpMBBUCcMtkqfa+tS36rSEII4wJ3F5rFSZ4YX29fRrG6cV1N9
jHcT7hCiObrelQO/InukHp598VLlxcGtx2HWOoU8S3RfzLfpY4SQGXL5crtnpOTo
xdz/I6AIPtlbCGsUSDuu6rDEBtnKr0APlrYUNWKRUT48SoaaGncli+SpU49YUDm5
Q9HK3kkPfE8IHf8B5YdNVQ0f83LC9XkvGOe+1RCMaPvPwDUN9f623tgCfteobeTB
djnyzbzGfxgQGMSBGdtRye9RolVpwphcNOQ8ib29JyujN0PxTQiZRiVw5wp4WAif
fli7UbzI17kBDQRU5NH9AQgAva39DHOyW0kpU52ebIGxj5XevbpLpxkl0jWlnCpe
ljG0mvNk4qf/57/6He6PrerX8cpnM4OH7ari0JGZJwAC3/X/ehmX3Q4TutWDD5wS
/455UDL/ZOfY9E8JPaUOvENEmMwiacezZLpkvPADvv7Yy6Bgn+T4oVwfjfWWBKJb
xc28dEw5gKiPbNbThj+qwT9lkCzpD87SDxXcdZKuv+hGDmhxp3BqrjH5yXlqgjyT
4NG9DYCOHrhJpzrF8BQe8aNhQ8uCxQc83hKgbB+QonLGQp5fJOzXGdp4ohAtMjOt
=Yk27
-----END PGP PUBLIC KEY BLOCK-----

Such a text can be contained in a public key file with extension .asc, for example:

testuser.public.key.asc

To be easy readable by human, information about the key can be reduced to the key ID and the key fingerprint, which look like this:

Key-ID: 0B4F9A19
Fingerprint: 6E010125DD2E874B8FF6A4BD2B3E29DE0B4F9A19

Key fingerprint is different for each key. To verify the signature is sufficient to ensure that the key with specific fingerprint belongs to a particular person.

See also: How PGP works

The identification of a public key as belonging to a particular user.

The Problem

As stated in Wikipedia:

All public key / private key cryptosystems have the same problem (The problem of correctly identifying a public key as belonging to a particular user), even if in slightly different guises and no fully satisfactory solution is known.

Existing systems of keys-based digital signature for documents are based on a personal visit to a certification center.

The key pair for the client is in many countries created by the certification center, and given to the client. In this case, a copy of the user's private key can remain in the certification center, i.e. not only user can have access to it. This problem is often not even realized by users. Often the keys for the client-bank systems are created this way. Although signature verification is reliable only if no one else except the owner has access to private key.

Also, the need for user to visit certification center personally, makes currently not possible (or very hard) to create a unified system that works around the world. While this is exactly the case, where having a system that work internationally is much more effective.

OpenPGP is currently not used in any State as a national standard, despite the obvious advantages of OpenPGP: it is convenient and understandable for the average user, and plentiful supply of software and libraries already exist, including free and open source software; and this is a standard that already familiar to many developers and users.

Our Solution

PGP's "Web of trust" was not a success, because, as stated Wikipedia:

Users have been willing to accept certificates and check their validity manually or to simply accept them. No satisfactory solution has been found for the underlying problem

We offer exactly the solution for this problem that is mentioned in Wikipedia as not yet found. We deny automatic key check, we are offering the user to check and download each key manually.

We make verification of key owner's identity and store data about this verification: who, when, using which document made verification. And unlike in 'Web of trust' there is an established procedure for key verification, i.e. known rules according to witch identity of the key owner have to be proven.

The user can make the information of the key or keys in the database available to all other users of the database, or available only for specified users or user group. Accordingly database user will have access to data about keys of others users, which is open to all users or shared with him, (for some cases, i.e. for arbitrators, including scans on the paper documents)

And we offer for the market the first legally relevant global system of public key's certification, that can be run around the world, or more precisely in all states where Hague Convention Abolishing the Requirement for Legalisation for Foreign Public Documents 1961 (Apostille Convention) and United Nations Convention on the Recognition and Enforcement of Foreign Arbitral Awards 1958 (New York Convention 1958) are recognized.

We can provide a legal mechanism for recognizing digitally signed contracts in almost every country: every digital contract in the need can be "transformed" in arbitral award recognized under The Convention on the Recognition and Enforcement of Foreign Arbitral Awards, and using modern technologies (web-server, databases, videoconferencing, e-mail) make international arbitration affordable even for small business and individual clients.

Legally electronic document can be used as an evidence in arbitral tribunal, and users do not need to recognize electronic documents and digital signatures in particular country, it is enough to recognize an arbitral award recognizing an agreement or obligation made using a digital signature.

So we use an international arbitration authority (our arbitral tribunal registered in London) as a 'proxy' between electronic documents standard and law enforcement in different countries.

For certifying a key the user have to pass the following procedure:

Physical person (natural person)

  1. The user generates OpenPGP keys ( .asc file) using the software on his or her computer (see. Appendix: "Recommended OpenPGP software for users") following the instructions on the site and/or instructions of this software. (from security reasons we will never provide key generation on our website, this is easier for user, but it is not the right way)

  2. User does login to our web server using Google his Google Account. It can be @gmail.com , or Google Account for any email address, see: https://accounts.google.com/SignUpWithoutGmail

  3. User uploads his/her public key to server, with some additional information: date of birth, description. His email address we get from his/her Google account, and his first and last name we read from his/her public key. ( Can be tested on www.cryptonomica.work/#/registration )

  4. The user verifies his public key with one or some of the following methods:

Accredited public notary or an authorized officer of our company (*implemented)

The public key can be verified at a accredited public notary (we start with this method, building the network of accredited notaries in different countries)

The accredited notary has access to our web-server and can put information about key owner verification directly to web-server.

To process verification user have to visit notary personally with his passport.

Network of accredited notaries is self-expanded as notary already accredited can provide accreditation to another public notary (for this he have to certify and store notary license of new accredited notary)

Currently verification in person provided by public notaries in Tel Aviv and Kyiv, and by Cryptonomica officers in New York and Moscow.

Any public notary (*to be implemented)

We can use the fact that a key is simply a character set, that can be printed on a paper, to which we can apply some legal manipulations: it should be hand-signed at a public notary, certified with an Apostille (internationally recognized under Apostille Convention), and after that mailed to us, and stored in paper form in our depository and verified in case of need by an expertise.

And thus such a key ('key certificate') can live in 2 forms: in electronic form in the database, and as a paper document in depository.

For this: Web-site generates for user an application form with uploaded key's ID and fingerprint, his/her data, and:

  1. His confirmation that this user's public key belongs to him.

  2. His statement, that he/she takes full responsibility for the safety of the private key, and that a signature of contracts and documents made with this key will be his hand-written signature equivalent.

  3. That the notary or other authorized person (solicitor) whose name appears in the this document and in attached and Apostille confirms that he checked the identity of the person signing the document in accordance with the laws of the State which issued the Apostille.

User prints an application form and attaches to it a copy of his passport. Then user goes to a notary or other person authorized to certify documents for Apostille in his jurisdiction, and get a certification and Apostille for these documents.

If required by the legislation in this jurisdiction, the document may be accompanied by a translation into the official language of this jurisdiction. User sends paper documents to our company.

We receive a document, put it in the depository, put scanned copy of paper document to database and mark the key in the on-line database as 'verified'. For the first time our company can process and store documents by our own staff, with an increase in the volume of documents processed we plan to outsource scanning, and storing documents. (see. Appendix: "Companies providing document processing and storage services (records management)")

Online identity verification (*implemented)

The procedure for online identity verification is as following:

  1. User logs in on web-site using his/her Google account (as explained above)

  2. User uploads two personal identifications documents. First: passport, this have to be passport with information on English (the one you use to get visas). Second: another document containing user's photo, first and last name in English and birth date, preferably driving license. Documents have to be in color, and in good quality. Images in formats .jpeg, .png, .gif accepted.

  3. User records short video using his webcam, where reads provided verification text. Video have to be in color and in good quality of sound and image, that allows any person easily recognize person on video.

  4. We verify user's phone number. User put his phone number in international format into form, and send to server. Than user receives sms-message with code in it, and have to provide this code to proceed with verification.

  5. User has to pay for verification with the credit card with the same first and last name as in his/her key (key certificate) and in provided passport.

  6. User have to check credit card bank statement and find description for charge for key verification, it looks like: 'CRYPTONOMICA 6691170'. The last 7 digits is unique code, and user has to enter this code on our web-site to prove that he/she is a legitimate owner of the credit card

  7. We also record and keep information about user's IP address, country and region, Internet provider, browser and OS used in verification process.

  8. All entered and recorded information have to be manually verified by our compliance officers, and, in case of need, we may ask user to provide additional verification data and/or short video-conference call via Skype or other program for video-conferences. We reserve the right, at our discretion, without explanation of reasons, to refuse to verify the key to any user (in this case payment will be refunded)

Verification data entered in the verification process will not be published publicly, these data will be available only to: 1) employees of our company, or persons associated with the company, or having a service contract with the company 2) accredited notaries, 3) arbitrators of the arbitration court when resolving disputes involving a person whose key is verified. User can, at his/her discretion, grant access to data entered during verification to other users of the service, or withdraw such access.

Using his digital signature from one of the recognized digital signature services (*to be implemented)

In the future user can use for key verification digital signature/key from another key service (currently we are researching e-Estonia)

Legal person (legal entity) i.e. companies, organizations (*to be implemented)

From security reasons, it should be no signatures of legal person per se.

But we can verify a natural person, as an authorized representative of the legal entity.

To be verified as an an authorized representative of the legal entity registered in any state (country), a user should be registered on our web-site and should have verified public key, as described above.

Than procedure of verification will be as follows:

  1. If this legal entity already registered on our database user chooses this legal entity, or if it not already on database, user should fill up a form for new legal entity with:

    • Name of legal person

    • State (country) of registration

    • Registration number

    • Registered address

    • Address for correspondence (if differs from registered address)

    • Director or directors

    • Registered agent in State of registration (if any)

  2. User should fill up form for his powers for this legal entity:

    • grounds for the powers (position as an officer or power of attorney)

    • term of the powers (unlimited, or until a certain date)

  3. User should provide a link to public registry, where he or she is stated as a director or other authorized representative of the legal entity, or send apostilled copies of documents in English confirming his powers as an authorized representative of the legal entity. If user provides paper documents, they have to be sent to records management company providing services for us.

  4. User gets verification code for legal entity. Code is unique for every verification. This legal entity should made payment for verification - wire transfer to our bank account with this code, and words "hereby {first name} {last name}> is authorized as our representative for term: {unlimited, or until a certain date}, verification code ..."

  5. User's key is considered as verified authorized representative of the legal entity.

Legal entity verification can be also done by an accredited notary (for the beginning we start with notary verification) - for this user have to provide to accredited notary documents about his/her powers to represent legal entity.

Once registered legal entity gets unique ID in our database, so if it changes it's name or even registration number (if possible in it's jurisdiction), we can keep all changes under the same ID.

Legal entity can have several authorized representatives. The representative, which verification has been made or updated later, can revoke the powers of previously verified representatives. In case of differences, the arbitral tribunal shall decide the dispute under it's Arbitration Rules.

Legal aspects and international arbitration.

Verification of digital signatures in transactions and in dispute resolution.

One of the major obstacles to the wide use of electronic signatures in international transactions is lack of standard for internationally legally recognized digital signature, and the practical difficulty of representing in court or other legal authority electronic documents with digital signatures - as such authority not only has to recognize such signatures, but also should have the appropriate software and skilled officers to work with electronic documents and to verify digital signatures.

In our project, we combine "certification authority" and the dispute resolution authority in one, thus user's keys are certified be the same organization which is authorized by users to resolve possible legal disputes between these users, and whose decision is legally enforceable internationally according to international law.

The Apostille Convention

The Hague Convention Abolishing the Requirement for Legalisation for Foreign Public Documents 1961, is also known as "The Apostille Convention", "The Apostille Treaty", "The Hague Convention 1961"

The Hague Convention 1961 establishes a special certificate: Apostille, affixed to official documents created in one state to be recognized in another State, which replaces the procedure of consular legalization. Apostilles are affixed by Competent Authorities designated by the government of a state which is party to the convention. A list of these authorities is maintained by the Hague Conference on Private International Law. Currently number of Contracting States to this Convention is 112.

To enforce arbitral award user receive arbitral award and copy of arbitral agreement on the paper with Apostille.

The U.N. Convention on the Recognition and Enforcement of Foreign Arbitral Awards, also known as the New York Convention 1958

The New York Convention 1958 requires courts of contracting states (currently 156) to give effect to private agreements to arbitrate and to recognize and enforce arbitration awards made in other contracting states.

As stated above, currently there is no system for digital signatures, that can be legally used internationally, but our users do not need to recognize electronic documents and digital signatures in particular country, it is enough to recognize an arbitral award recognizing an agreement or obligation made using a digital signature.

According to The New York Convention 1958 "each Contracting State shall recognize an agreement in writing under which the parties undertake to submit to arbitration all or any differences which have arisen or which may arise between them in respect of a defined legal relationship, whether contractual or not, concerning a subject matter capable of settlement by arbitration. Para. 2, Art. 2 of Convention states, that "the term "agreement in writing" shall include an arbitral clause in a contract or an arbitration agreement, signed by the parties or contained in an exchange of letters or telegrams." And it is now widely recognized that the exchange of electronic messages is an "agreement in writing" in the meaning of the Convention. See also p. 4 art. 7 UNCITRAL Model Law on International Commercial Arbitration.

The arbitration process in our arbitral tribunal will be conducted using the exchange of electronic documents and, if necessary, using video conferencing, making the process much more faster and cheaper compared to traditional arbitration.

The result of the arbitration proceeding can be formed also as the paper document (electronic document digitally signed in PGP standard can be printed) with Apostille, thus in the traditionally internationally recognized form, and enforceable under New York Convention 1958.

Accreditation of lawyers, and certification of documents in arbitral proceeding using lawyer's digital signature (*to be implemented)

In many jurisdictions, such as the United Kingdom, Israel, Ukraine and others, according to the law, licensed lawyers have the right to certify copies of documents they present to the court or to arbitral tribunal. Thus we are able to present to the court not only documents originally made in electronic form, but also scanned copies of paper documents, if they are certified by a digital signature of a lawyer involved in the case.

Accreditation of lawyers and law firms besides the usual key certification, will require providing additional documents (license to practice law) and additional fee.

The experience of on-line arbitration proceedings.

We have did several pilot arbitration proceedings, in the arbitral tribunal registered in London, with the use of on-line video conferencing, electronic documents, and digital signatures.

See Video - of real arbitration proceedings, resulting the award signed with digital signature, that has been recognized under New York Convention 1958.

We also have published some (depersonalized) arbitral awards (decision) from resolved cases online: github.com/Cryptonomica/arbitration-rules/tree/master/awards

Bitcoin or Ethereum Escrow-like Service.

The ability to quickly resolve disputes using electronic documents we can use to provide services as an intermediary (like escrow) in transactions with Bitcoin using multi-signature accounts. Multi-signature accounts have been recently added to Bitcoin software and they provide a completely new level of safety in operations with Bitcoin (see Bitcoin Multisig Wallet: The Future of Bitcoin) They can be used as for creating services like documentary letters of credit in traditional banking.

Currently such service is technically possible, but relevant legal procedures are missing.

The most known implementation of such service is Bitrated, but despite good web site, the legal aspects and procedure are completely ignored (no qualifications requirements for intermediaries, lack of written procedures, rules of evidence etc.)

Another and more advanced option is to use smart contracts on the Ethereum blockchain. Our team has practical experience in programming smart contracts on Ethereum.

Work-flow for cryptocurrency and blockchain users (Bitcoin, Ethereum)

In Bitcoin recommended and common practice, implemented by default in popular software, is to use a new account for each transaction, and accordingly to set to zero the account when making any transaction from this account for any amount (the remainder is transferred to the new owner's account) - this is because despite accounts can be anonymous, all accounts are open and transparent in the blockchain (public ledger of all accounts).

But using new account for every transaction creates a problem of identification of account's owner and proofing that the funds were really transferred to account of particular person (for example, to seller in the purchase and sale transaction)

If there is a database of verified public keys, we have convenient technical and legal platform for Bitcoin transactions: the payee (for example, seller) sends to payer signed with his public key and possibly encrypted with public key of receiver invoice containing his Bitcoin account number (witch can be new for every new transaction, and although payer can ensure he pays to account of payee, he pays every time to new account, and can not now all transactions of payee accounts)

And in case of need, there is a technical possibility to verify signer of the invoice, and the possibility to decide the difference, and get a legally enforceable decision.

And it is also possible to conclude agreements for the use of multi-signature accounts.

Planned solution for identity proof for Ethereum accounts.

'Ethereum Identity Proof' - working smart contract code on:

https://github.com/Cryptonomica/Ethereum-IdentityProof (prototype)

https://github.com/Cryptonomica/Ethereum-IdentityVerification (in testing, deployed on Rinkeby TestNet: https://rinkeby.etherscan.io/address/0xb9ffed00f17De4CDA41bF30bBe0E11B78E3A2c57 )

How it should work for users?

  1. Ethereum account sends to smart contract a request for verification, in this request he/she sends a fingerprint of his OpenPGP key verified by cryptonomica.net

  2. This smart contracts creates and sends back a string to sign (like: 'I hereby confirm that the address 0xdbb8b647497fc2dc4b9280b8ce505253129f12fd is my Ethereum address')

  3. Account owner signs this string with his OpenPGP key (online on our website or using desktop software) and sends back to smart-contract. And this signed string will be stored in smart contract along with user data such as name, surname, date of birth, citizenship. This will allow other smart contracts to automatically receive and process information about account owners on the Ethereum blockchain. We also plan to add other information, such as information of a person's accreditation as a qualified investor (in cooperation with licensed lawyers in relevant jurisdictions).

4.Information about verification is publicly visible - who needs to check can download notary verified public key from cryptonomica.net and check if owner of stated Ethereum accounts is also known owner of notary verified OpenPGP key.

  1. This can be used for legal binding and legally recognizable smart-contracts - with arbitration clause according to IACC Arbitration Rules, like in Bylaws of CoinOffering Ltd.

Server Architecture

We are building the server on Google App Engine platform using the built-in database App Engine Datastore, Google Cloud Endpoints + Objectify Framework

See an article (in Russian) Google Cloud Endpoints on Java by Viktor Ageyev on habrahabr.ru

We use some Google services and APIs provided with GAE and Google Cloud Endpoints, in particular for e-mail and user authentication using an @gmail account (including the possibility of two-factor authentication).

The back-end is implemented in Java. To work with the PGP on the server we use a free library Bouncy Castle Crypto APIs, see an article by Viktor Ageyev (in Russian)PGP with Bouncy Castle Cryptography Library on Java

The choice between GAE Python and GAE Java made in favor of Java, due to the existence of the Bouncy Castle library (acceptable implementation of PGP/GPG in pure Python is missing, and GAE does not allow the use of libraries in C or installing [GnuPG](https: //www.gnupg.org /) to the server)

For front end of the web site we use JavaScript-framework AngularJS, with some modules:

and CSS/JavaScript Framework Bootstrap version 4

OpenPGP functions (key generation, parsing keys, signing and encrypting text, signatures verification) on front-end are implemented using OpenPGP.js

Use of Google Endpoints makes possible in the future creating another clients for server (for example Desktop Application, Android etc.)

Code is open sourced and published on: https://github.com/Cryptonomica

Desktop Application

We started to develop cross-platform OpenPGP desktop application integrated with our web-server. It's open sourced, code published on https://github.com/Cryptonomica/Cryptonomica.DesktopApp , releases on https://github.com/Cryptonomica/Cryptonomica.DesktopApp/releases

Technologies used:

Intellectual Property

Trade mark "Cryptonomica" is registered in the U.K. (Owner of trade mark is IACC)

Planned sources of income, prices.

  1. Fees for key verification.

  2. Fee for authorization of physical person as representative of legal person

  3. Arbitration fee, including escrow-like service using multi-signature accounts in Bitcoin: ~ 3% of claim, but not less than 1000$, can be lowered for some cases by registrar of the IACC.

  4. Fee for accreditation lawyers and law firms at arbitration court (not required to appear in the court): 100$ for lawyer, 300$ for law firm

  5. Consulting, seminars.

Market

Current leader on electronic document solutions market DocuSign reports more than 50M users, and 50,000 new unique users joining its network per day, founded by Google and has more than $3 billion valuation, offers packages from $20 to $125 per month – for completely wrong solution.

See: DocuSign Momentum Approaches Escape Velocity("Forbes")

Leading international arbitration institutions are having about 2000 – 3000 new cases a year, and this is mostly affordable for big businesses.

Promotion and Acquiring Users

Social networks

IACC on LinkedIn

IACC on Facebook

IACC on F6S

Slack server

Design of the company.

The Team

Co-founders

Legal entity

U.K. is currently most popular jurisdiction for international arbitration. London is a major international legal center and more international and commercial arbitrations take place there than in any other city in the world (see: http://en.wikipedia.org/wiki/Legal_services_in_the_United_Kingdom ) Thus our arbitration institution was registered in London, and operates under U.K. law. Arbitral awards need to be apostilled, and U.K. Apostille can be checked on-line - this is good for enforcement.

The company is registered under the name "The International Arbitration and Cryptography Centre Limited" on 16th January 2015, with registered address in London.

In the future is possible to open also an Israeli or/and U.S. company for operative work.

Appendixes

Competitors

Electronic signature providers

DocuSign, and other electronic signature providers Current leader on electronic document solution s market DocuSign reports more than 50M users, and 50,000 new unique users joining its network per day, founded by Google and has more than $3 billion valuation, offers packages from $20 to $125 per month for completely wrong solution.

eSign (EchoSign) by Adobe. In March 2014, Adobe announced EchoSign and its Document Web services revenues had hit $164,000,000 in ARR (see: https://en.wikipedia.org/wiki/EchoSign )

Digital signature keys storage and identity verification

Web of trust

Keybase

Bitcoin escrow and arbitration

Bitrated

International arbitration

The London Court of International Arbitration (LCIA)

ICC International Court of Arbitration

The Arbitration Institute of the Stockholm Chamber of Commerce (SCC)

American Arbitration Association

and other arbitration organizations

Leading international arbitration institutions are having about 2000 – 3000 new cases a year, and this is mostly affordable for big businesses.

Why OpenPGP?

This is the standard used by people who really work with security.

See what Bruce Schneier is using, what Adam Back is using, what Python core developers, Bitcoin core developers are using, and many others: they use PGP/GPG (which on some strange reason is not yet a legal standard for digital signature in any State of the World)

OpenPGP has most developed ecosystem, and most user-friendly software.

Recommended OpenPGP software for users

Kleopatra (Linux, Windows)

Free, open-source [project website](http: //www.kde.org/applications/utilities/kleopatra/)

To install on Ubuntu:

sudo apt-get install kleopatra

For Windows: Kleopatra is a part of the package Gpg4win

GPG Suite (Mac)

GPG Suite free software for OS X.

Enigmail (Linux, Windows, Mac)

Enigmail Free, open source. Add-on for the email program Thunderbird (also free, open sourced and cross-platform)

Enigmail is easy and convenient for signing and encrypting e-mail.

Email clients supporting PGP/GPG

GnuPG encryption support has been integrated into KMail and Evolution, the graphical e-mail clients found in KDE and GNOME, the most popular Linux desktops.

Docs, manuals, further reading

An Introduction to Cryptography

GPG Tutorial by Alan Eliasen

How To Use GPG to Encrypt and Sign Messages on an Ubuntu 12.04 VPS

gpg2 - Linux man page

Companies providing document processing and storage services (records management)

Records Management companies:

Iron Mountain

Crown Records Management

Restore Document Management

Recall

Usually such companies offer maintenance of a database of documents and access to the scanned copies.

www.cryptonomica.net

Add a custom sidebar
Clone this wiki locally