AU2020203335A1 - Cryptosystem, systems and methods for private secure zero-knowledge end-to-end encrypted delivery of electronic documents using merely verified postal addresses as a routing mechanism - Google Patents

Abstract

Novel systems, methods and cryptosystem are proposed that make it possible to deliver electronic documents, contents and artefacts using only a postal address as the destination address, on a zero-knowledge completely private basis based on end-to-end encryption, assuring that only the right recipient(s) with verified access to the postal address will receive such documents/artefacts in a trust-less setting, and, with the data transfer intermediary to remain unaware of the contents of such artefacts and unaware of names and surnames of the recipients and senders, effectively protecting the people's and organizations' privacy, while proposing a feasible mechanism to replace physical posted letters with an electronic alternative. 1/3 - ---------------- * ~ ~ c ~ coI ---I cC I-o) C 0 0 (V 10 ' cc 0) -- o I z (D 0 1 C) I C) 0 = 5 U) 1010 SendI ------- --------------------- -

Description

1/3

- --------- ------

* ~ ~ c ~ coI I ---

cC

I-o)

C 0 0

(V 10

' cc 0)

-- o I z (D

0 1 C)

I C)

0 = 5

U)

1010 SendI

------- ------------------ - CRYPTOSYSTEM, SYSTEMS AND METHODS FOR PRIVATE SECURE ZERO KNOWLEDGE END-TO-END ENCRYPTED DELIVERY OF ELECTRONIC DOCUMENTS USING MERELY VERIFIED POSTAL ADDRESSES AS A ROUTING MECHANISM TECHNICAL FIELD

This invention relates to cryptography. To be more specific, this invention pertains to zero-knowledge private delivery of electronic documents and contents using postal addresses as a novel replacement to physical posted letters.

BACKGROUND

Billions of physical letters and documents are delivered by post companies all over the world every year. This leads to a range of problems and issues, including wastages of paper, costs of paper and costs of delivery, security and privacy issues, disposal issues of important posted documents, poor end user experience with not having access to their physical letters in a centralized fashion, lack of ability to search for and find information easily and many more.

Most private bill and statement issuers have already turned to emailing their bills and statements once they get their customers' details confirmed and verified. Apart from the need to know and verify the details of the recipients (e.g. their email address), such issuers mostly refrain from emailing sensitive information to customers due to security and privacy concerns caused by the fact that emails can mostly be accessed by the intermediary email service delivery platform. Hence, most times, emails are used to notify users of the fact that a new bill or statement has become available to them without including the real document, or, if such emails include private statements or bills, they are mostly sent as attachments in more protected formats like password-protected PDFs, which cause their own inconveniences.

Still, email has never been able to replace physical mail since in the context of physical mail, still the goal is to be able to deliver to the destination using only and only the mailing address and no other direct or indirect routing mechanism or a secondary address like an email address. Hence, some post companies proposed the idea of opening envelopes, digitizing letters and emailing them to their customers which requires a significant level of trust to the post service provider and has never been deemed a viable solution to the problem of paper letters delivered to postal addresses due to a range of privacy and security issues.

Another dimension is that people have a need to ensure their names and addresses are protected and the idea of publicizing extra addresses with the goal to make electronic document delivery to them possible is against that need; hence any solutions to solve this problem must ensure people's addresses and names are protected and remain private to the world (including the data transfer intermediary).

Accordingly, there is a clear need in the art to provide a solution for zero knowledge private delivery of electronic documents using only postal addresses as the delivery address to assure security, privacy and correct delivery without the need for secondary other address or routing mechanisms and/or types except the postal address that has been left unaddressed in previous art.

SUMMARY OF INVENTION

The problem stated above is that in order to deliver a document to a postal address in electronic format, the sender needs to know extra details of the recipient at the address which is impossible unless the recipient provides extra secondary contacts or addresses to the sender hence in electronic delivery of documents, the postal address is effectively unusable on its own as a routing or addressing mechanism. On the other hand, even if such extra details or addresses are provided by the recipient, still delivering electronic documents via email or similar electronic delivery methods may be unsecure and non-private and requires a very high level of trust in the data transfer intermediary hence the long-lasting issues of physical posted letters are still creating a lot of pain for people, organizations and the environment. The two aspects of lack of possibility to send electronic documents using merely a postal address and the privacy and security issues of having to trust an intermediary to transfer such documents to its intended recipients owning a postal address have prevented the digitization of physical posted letters which has caused huge costs, environmental issues and inconveniences for the public.

To solve this problem, novel systems, methods and cryptosystem are proposed that make it possible to deliver electronic documents, contents and artefacts using only a postal address as the destination address, on a zero-knowledge completely private basis based on end-to-end encryption, assuring that only the right recipient(s) with verified access to the postal address will receive such documents/artefacts in a trust-less setting, and, with the data transfer intermediary to remain unaware of the contents of such artefacts and unaware of names and surnames of the recipients and senders, effectively protecting the people's and organizations' privacy, while proposing a feasible mechanism to replace physical posted letters with an electronic alternative.

In an embodiment, the proposed method includes 1) validation of postal addresses which may include geolocation services, 2) client-side software systems (apps, Software Development Kits SDKs and Application Development Interfaces APIs), performing local client-side cryptography with access to secure key storage facilities (e.g. key chain storage), 3) verifying the ownership of an address by a Postal Address Claimant, which may or may not include 3rd party name and address verification service providers, or, may or may not include the selection of registration secrets by the claimant and the generation and physical postage of secure random registration tokens by the intermediary, without such tokens, first and surnames being maintained in any form or shape or derivations by the intermediary post registration completion, and after successful registration, the generation of a range of cryptographic keypair sets, one set per the address, called the Postal Address Keypair Set, generated by the first claimant at the address which is shared with subsequent claimants in a secure manner, and one set per each individual named claimant, which will be used by senders to look up and exchange public keys to derive private session keys to perform end-to-end encryption per each future message, with all such keys generated at client side and only public keys being shared with the intermediary, and, with only random salts and verifiers for each name and surname, as per a zero knowledge password authentication protocol to be maintained by the intermediary per each name and surname under each postal address, 4) Verifying the ownership and correctness of the details of a legal entity that can own a range of sending divisions each with their own cryptographic key sets while being able to send on behalf of the entity, 5) the end-to-end encryption protocol that uses the exchange of public key sets associated with a postal address as well as public key sets of named individuals at a postal address, without supplying name and surnames to the intermediary for the lookup of keys using a zero-knowledge password authentication protocol, hence facilitating a zero-knowledge routing to name and surnames at postal addresses, and facilitating the end-to-end encryption of messages between senders and recipients to generate a range of private secrets used for encryption and singing of messages, 6) Sender's digital signature scheme which involves the overall byte list of the message containing all artefacts/documents/contents as well as the name and address of the sender to then be digitally signed using a long-term identity private key, at client side, 7) the document/artefact/content reception process which involves the periodic synchronization of a client-side software system or application or SDKs against a private list of encrypted messages as uploaded by senders, stored on intermediary servers, indexed by the postal address (or its derivations) for unnamed recipients at a postal address, and for named recipients at a postal address, indexed by a random identifier as well as salts and verifiers associated with each recipient's name and surname as per the zero-knowledge password authentication protocol, created at client side at the time of registration of a named recipient at the postal address, then looking up the relevant public key sets of the sender, using the postal address of the sender and their random identifier, which are saved as the metadata of the message, as uploaded by senders, stored on intermediary servers, and then re-constructing all private secrets as senders created them, in order to decrypt messages and optionally re-encrypting them (with random independent-per-message keys unknown to the intermediary) and uploading them in an online private bucket for portable cloud-based multi-device access at a later stage, with such random keys being encrypted themselves with keys only known to the recipient and then uploaded with the encrypted messages to the bucket.

In one embodiment, the proposed systems, methods and cryptosystem uses a range of salts and verifiers and random identifiers for a recipient at a postal address to facilitate a routing mechanism that does not involve the intermediary to save such names and surnames in any form or shape or derivations and with the end-to-end encryption of the contents of messages, documents, contents and artefacts based on private keys unknown to the intermediary, the proposed method assures complete privacy of the senders and recipients and their messages.

Another aspect of the invention is the possibility for the recipient to verify the correctness and tamper-resistance attribute of the messages they receive via verifying the digital signatures included in the messages, while optionally, a recipient can also sign the signature of the sender in an optional reception acknowledgement message, sent back to the sender.

Another aspect of the invention is to prevent an attacker or the intermediary to add an unauthorized recipient to a postal address, named or unnamed, since decrypting messages to a recipient and a postal address still requires accessing the private keys of such postal address which are only known to the legitimate residents of such address.

Another aspect of the invention is the intermediary's ability to verify a message has been sent from a sender to a recipient without knowledge of the name and surnames of the parties, which is facilitated through looking up the random identifier of the sender during the reception process.

DESCRIPTION OF THE DRAWINGS

Figure 1 demonstrates the high-level logical building blocks of the proposed system for secure zero-knowledge transfer of documents, contents and artefacts using postal addresses.

Figure 2 demonstrates the name and address verification process without the intermediary becoming aware of name(s) and surname(s) or persisting them in any form or shape or derivations.

Figure 3 demonstrates the key generation and distribution between the recipients at a postal address as well as how individual keypair sets are generated for each recipient at a postal address.

DETAILED DESCRIPTION OF INVENTION

The inventor hereby proposes a novel method for the delivery of electronic documents, contents and artefacts using merely a postal address as the destination address while maintaining zero knowledge of the contents of such material and of the name and surnames of senders and receivers, making use of end-to-end encryption. The present invention is described in enabling detail in the following examples, which may represent more than one embodiment of the present invention.

Referring to Figure 1, the high-level logical building blocks of the proposed digital document delivery system using postal addresses includes a sender's private computing space 102 belonging to a sender 101, who may optionally be using a virtual print driver 111 that wrap the functionality of software development kits 105 as a consumable print service provider with the SDKs 105 performing client-side end-to-end encryption for the delivery of documents to a recipient 104 owning a private computing space 103 with access to SDKs 106 performing end-to-end encryption. Outside of these private computational spaces in which private cryptographic keys are securely maintained and not shared with the outside universe, communication between senders and recipients is facilitated via the public internet 108 by a data transfer intermediary 107, owning and operating online backends which use channels 109 and 110 with transport layer security to transfer data between senders and recipients.

In one embodiment, the use of a virtual print driver 111 can abstract and hide all underlying integration complexities to deliver printed documents using postal addresses as a routing mechanism with the printer driver asking for the destination delivery address and other relevant details which will then initiate the document sending process over an end-to end encrypted protocol to deliver documents, contents and artefacts in digital format to recipients with verified access to the postal address used.

Referring to Figure 2, in one embodiment, the address verification and registration process can be performed by the address claimant to provide their address and choose a strong address registration secret for the address 200. Then they use a zero-knowledge password authentication protocol to generate a salt and a verifier at client side to be shared with the intermediary 202, which then will generate its own secure random token to print and use physical printed mail to deliver the random token to the physical address 203. Once delivered and received by the claimant 204, the claimant then reuses their selected strong registration secret and the received registration token with the zero-knowledge password authentication protocol to look up the salts from the intermediary and generate verifiers and verify they have the same secret used at the time of registration and the same token as generated by the intermediary at the time of registration 205. Once verified, the intermediary deletes any token, salt and verifies associated with the token, as well as the name and the surname, and then the claimant is given the option to register using name and surname which will then lead to them being able to receive messages sent to them at the postal address 207. They may choose multiple names including past names in this process. If they choose not to register using their name and surname, they will only receive unnamed messages that will be sent to the postal address (not the named messaged sent to the same postal address). When choosing to register with name and surname, the intermediary will still remain unaware of such details since at client side, the claimant uses each name and surname with the zero-knowledge password authentication protocol to generate a random salt and a verifier 209 which will be shared with the intermediary, out of which, one will not be able to derive such details back. In effect, the intermediary does not save any name or surnames in any form or shape, not in hash nor encrypted format. In the next step, the claimant will generate their own individual keypair set 210. If the claimant is the first to register an address, which is verified by the intermediary 213, they generate a keypair set for the postal address 211. If the claimant is not the first claimant of the postal address, then they will either receive the keypair set of the postal address from the first claimant (e.g. via direct end-to-end encrypted message), or, agree upon a new keypair set using a group key agreement scheme 214. Next, the claimant sends all the public key sets generated as explained to the intermediary which it will save against the postal address and the recipient using a random index for the recipient (since the intermediary remains unaware of the names and surnames of the claimant).

Referring to Figure 2, in another embodiment, a 3rd party online name and address verifying service provider can be contacted (through integration) to get the optional name(s) and surname(s) and the mandatory postal address provided by the claimant verified 208. Once verified, without the intermediary persisting names and surnames, at client side, the process to complete the registration of the postal address continues 207.

Referring to Figure 3, Each postal address 305 will be allocated a keypair set 313 which is created at client side by the first claimant of the address 301 at the time of first successful verification of the postal address by a claimant. This keypair set will then be shared with the rest of the successful claimants of the same postal address through a group key sharing scheme, the simplest form of which is for the first claimant to send it to the rest of the claimants via end-to-end encrypted message(s) via push notifications or any other applicable means. In effect, all recipients at the same postal address are treated like the members of a group that can be sent a message via the postal address and all share the same keypair sets related to the postal address. If a resident leaves the postal address, it becomes necessary to refresh the keypair set of the postal address to improve security. Each individual claimant, also generates an individual keypair set 306, 307, 308, 309 at the time of registration. All such keys are generated at client side with only public keys being shared with the data transfer intermediary, which are saved alongside with a random identifier, and the salt and verifier, generated at client side at the time of address registration by the individual, as per the zero-knowledge password authentication algorithm. The same goes for a sender 311 who is also a registered recipient at their own postal address owning their own keypair set 312. To send an unnamed message to a postal address 305,which will be received by all registered recipients at the postal address, the sender 311 only looks up the Public Keypair Set of the postal address, generates ephemeral keypair sets and uses them alongside own private keypair sets to derive private session secrets and then uploads the encrypted message into the box belonging to the Postal Address alongside with public ephemeral keys generated and their own postal address and random identifier, as metadata of the message. To send a named message to an individual recipient at a postal address, the sender looks up the Public Keypair Set of the postal address, uses zero-knowledge password protocol against each of the current address claimants, whichever is verified would be the right recipient (since the intermediary has zero knowledge of name and surnames). Then the sender looks up the relevant recipient's public keypair set, then generates ephemeral keypair sets and uses the recipient's public keypair set and the public keypair set of the Postal Address together alongside own private keypair sets to derive private session secrets then uploads the encrypted message, alongside with the public ephemeral keys and their own postal address and random identifier into the list belonging to the recipient. All recipients at the same postal address, periodically download the messages sent to the unnamed box of the postal address, use the private key set of the postal address and the public ephemeral keys included with the message, as well as the public keypair set of the sender (which is looked up using the sender's random identifier and postal address) to derive the same private session keys to decrypt the message. For the intermediary to allow access to a box at a postal address, a client must know the postal address and own the private key set associated with the address (which could be handled by asking for a random authentication challenge to be signed by the client using the private key set of the postal address to be then verified by the intermediary using the public key set of the postal address). For the intermediary to allow access to a named box at a postal address, a client must know the postal address, their random identifier, and own the private key set associated with the address, and, own the private key set belonging to the recipient, and, be able to verify the name and surname combo via the zero knowledge password protocol. A recipient periodically downloads all messages sent to their named box at an address, then uses their own private key set, and the private key set of the postal address, and the public ephemeral key included in the message, and the public key sets of the sender (looked up using the postal address of the sender and their random identifier) to derive the same session secret to decrypt their personal message. Since sending a message to a name and surname combination at a postal address still requires the keypair set of the postal address, an attacker cannot simply add themselves to the list of recipients at a postal address and be able to decrypt messages sent to the postal address in an unnamed form. Since the process includes the lookup of the sender's public key set using their postal address and random identifier, the data transfer intermediary can remain aware that a message from a sender at a postal address has been delivered to a recipient at another postal address despite remaining unaware of the name and surname of the parties involved, as such details are not shared with the intermediary.

In one embodiment, the proposed systems, methods and cryptosystem uses a range of salts and verifiers and random identifiers for a recipient at a postal address to facilitate a routing mechanism that does not involve the intermediary to save such names and surnames in any form or shape or derivations. To achieve this, the intermediary only maintains a indexed list which contains public key sets associated with postal addresses and named individuals at such postal addresses, each having their own row independent in the list (one per postal address, and one per each named individual at the address). At the first level, all lookups of public key sets happen by finding the postal address in the list and extracting the public key sets of the postal address. If the message is being sent to unnamed receipts at the postal address, the key sets are used to derive private secrets to encrypt messages and save them in the list in the same row, as the unnamed box of the same postal address. If the message is being sent to a named recipient, the intermediary can not be queried to show which row of the list includes the relevant public keys of the recipient. To look the right row up, the sender first looks up the row at the postal address and then uses the name and surname of the recipient, at client side, without sharing or sending them to the intermediary, and then traverses all salts and verifiers under that postal address from the intermediary, and tries verifying to the intermediary that they have the right name and surname, by executing the zero-knowledge password authentication protocol (with name and surname being the password). The row that is verified will be picked to look up the public key sets from, if any. If none is found, the message can not be sent (i.e. if the recipient is no longer at the postal address). Despite having to query all such rows, the proposed method assures zero knowledge of the intermediary of the names and surnames of senders and recipients. Each row of the list for a named recipient also is allocated a random identifier at the time of registration which is included together with the postal address as a plain sender's address with a message so that the recipient can look up the public key sets of the sender at the time of reception which makes it possible not to have to include names and surnames of the sender for the purpose of such lookups.

In one embodiment, instead of using a postal address as an index, any derivation of a postal address (e.g. geocode, geohash etc...) can be used whenever the postal address has been used to lookup other parameters.

In one embodiment, upon certain events, which can be notified to the intermediary through 3rd party systems (e.g. government agencies, land registries, tenancy directories, tenancy contract management agencies etc...), the access of an individual to a postal address can be revoked by removing their relevant salt, verifier and random id and all public key sets from the postal address (obviously using the zero-knowledge password authentication protocol in doing so to find the right recipient at the address to remove without revealing the name and surname). Once this is done, all active recipients of the postal address must agree upon a new shared keypair set for the postal address and update the intermediary servers with the newly generate public key sets.

In one embodiment, once a sender's private key set and the ephemeral key set they generate as well as a recipient's public key set are used to derive a common shared secret, that secret is fed into a key derivation function (e.g. HKDF (Krawczyk and Eronen, 2010)) to derive a set of keys like private symmetric encryption keys, private hash message authentication code (HMAC(Krawczyk et al., 1997)) used for authenticating contents between parties, and private digital signature keys based on HMAC (used by recipients to sign the digital signature of senders).

In one embodiment, an end-to-end encrypted key exchange protocol like Extended Triple Diffie-Hellman (Moxie Marlinspike, 2016) can be used to derive common shared secrets between senders and receivers only by exchanging public information where a set of one-time keys may be required to be generated frequently and uploaded to an intermediary server. In such cases, these keys have been referred to as public key set which would obviously have a very short lifespan (only one message).

In one embodiment, the process to send documents and messages using a postal address may comprise the steps of a. validating the postal address using geolocation services, b. looking up the public cryptographic key sets relevant based on the geolocation or geohash of the postal address.

In one embodiment, if recipients choose to do so, with the purpose of preventing unsolicited deliveries to recipients, recipients may choose to block messages from senders which fulfill certain filtering rules, which would then inform the intermediary of blocking such messages from being sent to the recipient.

In one embodiment, no names and surnames are persisted by the data transfer intermediary in any form or shape or derivation assuring the intermediary's zero knowledge of such details. Instead, at the time of registration, each name and surname pair, which may include previous names and surnames, are treated like secrets and using a zero-knowledge password authentication protocol like Secure Remote Password (stanford.edu), a verifier and salt against each combination is calculated at client side and then shared with and persisted by the intermediary. At the time of sending a document or artefact to a named recipient at a postal address, a sender will have to know the name and surname and address combination of the recipient in order to be able to send to recipients. This verification process involves the sender to retrieve all salts and verifiers of all named boxes under a postal address (each belonging to a name, surname and address combination), and try to prove, at client side, that they have the right name, surname and address combination using the zero-knowledge password authentication protocol. Once verified, they may be given permission to send artefacts to the recipient's address. This scheme assures the intermediary remains completely unaware of name, surname and address combinations hence protecting recipients' privacy and anonymity whilst still enabling a message routing mechanism based upon postal addresses, names and surnames.

In one embodiment, a legal entity, may have to verify its details (e.g. business registration identifiers or tax identifiers etc..) before being able to send artefacts or documents on behalf of such entities. This process may involve the use of 3rdparty business or legal entity identification service providers. Unlike a private individual address claimant whose address verification and claiming process involves the generation of a keypair set and is anonymous, the registration of a legal entity may be selected not to be anonymous and may involve the generation of multiple series of cryptographic keypairs, each for a division or individual from within the entity (e.g. sales, customer service etc...). Such entities will have the possibility to own multiple divisions sending out documents to postal addresses, all under the same entity name.

In one embodiment, a list of long-term cryptographic identity keypairs is generated upon the registration time by address claimants at client side with the private keys maintained at client side and public keys shared with the intermediary. Private keys are used to digitally sign artefacts sent by sender to others. Upon reception of a document or artefact from a sender, the recipient looks up the public keys associated with the sender from the intermediary's online backends and verifies the signature using the contents of such artefacts hence assuring accuracy, tamper resistance and non-repudiation of the message and artefacts transferred.

In one embodiment, if the sender has chosen to do so and if the recipient is willing to do so, a recipient's reception acknowledgement message may be compiled by the recipient at client side using their own private keys and send back to the sender. This acknowledgement may be digitally signed using a shared private secret as a singing key which remains unknown to the universe (except the sender and receiver). This private signature key is then used to sign the digital signature of the sender in the original artefact(s) as its input, which remains private from the intermediary and the world, hence providing a method for private acknowledgement of reception. Effectively, the sender can regenerate the original signature (if not persisting it) and the private signature key derived in the original sent message to verify the recipient's acknowledgement message.

In one embodiment, all the client-side operations highlighted above can be performed and managed at client side using a mobile, tablet or desktop application or software system making using of secure key storage options like keychain.

In one embodiment, all the client-side operations highlighted above can be performed and managed at client side using a web-based application or software system making using of WebCrypto API (mozilla.org, 2020), performing all cryptographic operations within the browser. In such a case, all locally saved private keys may be encrypted using locally generated random keys using a symmetric encryption key which can be persisted as a CryotpKey object, which will be non-debugable and will be persisted by the browser in a protected fashion. Alternatively, they may all be persisted in encrypted format using a locally-derived key derived from a password which is chosen by the user and not shared in any form or shape, not even hashed or derived, by the data transfer intermediary.

In one embodiment, all locally-saved information (received or sent artefacts, documents and cryptographic keys) are saved locally on a personal device (e.g. desktop, mobile, tablet) using encryption at rest with keys not shared with any parties, that are either generated randomly and persisted using secure key storage (e.g. keychain), or, encrypted using keys derived from locally selected passwords which are not shared with the data transfer intermediary in any form or shape or derivation.

In one embodiment, despite all client-side operations and client-side storage of delivered and sent letters, artefacts and documents through the proposed scheme, for improved portability and multi-device access, for the purpose of web-based access to the same contents, a synchronization scheme can be used comprising these steps: 1) the user singing up in a web-based globally-available software system, 2) at the time of registration, at client side, an elliptic curve keypair, the Online Synch keypair, is created with the public key being shared with the data transfer intermediary, 3) the private key is handed to the user to be maintained in a secure fashion, or, for better portability and availability and lack of dependence on supplying a key all the time in future, the private key is encrypted at client side, using a key derived from alocally-selected password, the Master Password, using a slowed password-based key derivation function like PBKDF2 or ARGON or BCRYPT or the like, with a high level of computational cost, without being shared in any form or shape with the data transfer intermediary. Then the encrypted version of the private Online Synch key is saved by the data transfer intermediary, 4) All client-side applications or software systems on different devices belonging to the same account holder will then download the public component of the Online Synch key and save it securely, 5) Every time, one of the devices receives a new document, artefact or content, once received and saved locally, then an ephemeral elliptic curve key is generated independently for each artefact, 6) the private ephemeral key alongside with the public Online Synch key are fed into the Elliptic-curve Diffie-Hellman (ECDH) function to derive an artefact saving seed, and then the seed is fed into a hash based key derivation function like HKDF to generate a symmetric encryption key (and other relevant parameters like initialization vectors), 7) the symmetric encryption key is then used to encrypt the contents of the artefact, 8) the encrypted artefact is then uploaded and shared with the data transfer intermediary alongside with the public ephemeral key generated at step 5, and all other relevant parameters (e.g. initialization vectors), 9) at the time of viewing and accessing such contents under the web-based system, the user is asked to either provide their private Online Synch key, or alternatively, it is retrieved in encrypted format from the data transfer intermediary, with the user being asked to provide their master password to then perform a local decryption of the key using the same password based key derivation function in step 3, leading to the reconstruction of the private key by the browser, which will be treated like a private CryptoKey and handled to live for a short time in the browser, ) the public Online Synch key is retried and provided by the data transfer intermediary, 11) to access each encrypted artefact belonging to the user and saved by the intermediary, it is first downloaded at client side alongside all parameters (e.g. initialization vectors and public ephemeral elliptic curve key), 12) the private Online Synch key and then public ephemeral elliptic curve key of the artefact are then fed into the ECDH function to re construct the same artefact saving seed, and then the seed is fed into a hash based key derivation function like HKDF to generate a symmetric encryption key (and other relevant parameters like initialization vectors), 13) the artefact is decrypted at client-side using the re-constructed symmetric artefact encryption key and initialization vectors and demonstrated to the user.

In one embodiment, despite all client-side operations and client-side storage of delivered and sent letters, artefacts and documents through the proposed scheme, for improved portability and multi-device access, for the purpose of web-based access to the same contents, a synchronization scheme can be used comprising these steps: 1) the user singing up in a web-based globally-available software system, 2) at the time of registration, at client side, an RSA keypair, the Online Synch keypair, is created with the public key being shared with the data transfer intermediary, 3) the private key is handed to the user to be maintained in a secure fashion, or, for better portability and availability and lack of dependence on supplying a key all the time in future, the private key is encrypted at client side, using a key derived from a locally-selected password, the Master Password, using a slowed password-based key derivation function like PBKDF2 or ARGON or BCRYPT or the like, with a high level of computational cost, without being shared in any form or shape with the data transfer intermediary. Then the encrypted version of the private Online Synch key is saved by the data transfer intermediary, 4) All client-side applications or software systems on different devices belonging to the same account holder will then download the public component of the Online Synch key and save it securely, 5) Every time, one of the devices receives a new document, artefact or content, once received and saved locally, then a secure random symmetric encryption key (and other relevant parameters like initialization vectors) are generated, 6) the symmetric key is then encrypted using the public Online Synch key, 7) the symmetric encryption key is then used to encrypt the contents of the artefact, 8) the encrypted artefact is then uploaded and shared with the data transfer intermediary alongside with the encrypted symmetric artefact encryption key, as well as all other relevant parameters (e.g. initialization vectors which could be generated randomly), 9) at the time of viewing and accessing such contents under the web-based system, the user is asked to either provide their private Online Synch key, or alternatively, it is retrieved in encrypted format from the data transfer intermediary, with the user being asked to provide their master password to then perform a local decryption of the key using the same password based key derivation function in step 3, leading to the reconstruction of the private RSA key by the browser, which will be treated like a private CryptoKey and handled to live for a short time in the browser, 10) to access each encrypted artefact belonging to the user and saved by the intermediary, it is first downloaded at client side alongside all parameters (e.g. initialization vectors and the encrypted symmetric artefact encryption key), 12) the private Online Synch key is used to decrypt the encrypted symmetric artefact encryption key at client side while other required parameters like initialization vectors are all available at client side, 13) the artefact is decrypted at client-side using the re-constructed symmetric artefact encryption key and initialization vectors and demonstrated to the user.

REFERENCES

KRAWCZYK, H., BELLARE, M. & CANETTI, R. 1997. HMAC: Keyed-hashing for message authentication. RFc 2104, February. KRAWCZYK, H. & ERONEN, P. 2010. Hmac-based extract-and-expand key derivation function (hkdf). RFC 5869, May. MOXIE MARLINSPIKE, T. P. 2016. The X3DH KeyAgreement Protocol [Online]. Available: https://signal.org/docs/specifications/x3dh/ [Accessed]. MOZILLA.ORG. 2020. Web Crypto API [Online]. Available: https:/developer.mozilIa.org/en-US/docs/Web/API/Web Crypto API [Accessed]. STANFORD.EDU. What is SRP? [Online]. Available: http://srp.stanford.edu/whatisit.html

[Accessed].

Claims (1)

1. Systems, methods and cryptosystem for delivering electronic documents, contents and artefacts using merely a postal address as the destination address, with preservation of privacy and data transfer intermediary's zero knowledge of the contents of such documents/contents/artefacts as well as zero knowledge of senders' and recipients' name(s) and surname(s) based on end-to-end encryption, comprising a. A Data Transfer Intermediary owning and operating online backends b. Validation of postal addresses which may include geolocation services c. Client-side software systems, applications (e.g. mobile or web or desktop apps), or Application Programming Interface (API) clients and/or software development kits (SDKs) with client-side cryptographic capabilities, and access to secure key storage facilities (e.g. key chain storage) d. Verifying the ownership of an address by a Postal Address Claimant which may involve the use of 3rd party identity verification service providers and/or may involve the selection of registration secrets by the claimant and the generation of secure random registration tokens by the intermediary that is delivered to the claimant using physical mail, without first and surnames and registration tokens being maintained in any form or shape or derivations by the intermediary post registration, and once the validation completes, the generation of a range of cryptographic keypair sets, one set per the address, i.e. the Postal Address Keypair Set, generated by the first claimant at the address which is shared with subsequent claimants in a secure manner, and one set per each individual claimant, which will be used by senders to look up and exchange public keys to derive private session keys to perform end to-end encryption per each future message, with all such keys generated at client side and only public keys being shared with the intermediary, and, with only random salts and verifiers for each name and surname, as per a zero knowledge password authentication protocol to be maintained by the intermediary per each name and surname under each postal address, with the salt being looked up by the sender, and the verifier being used by the intermediary, to verify that a sender, at the time of sending, has knowledge of the right name and surname at the postal address to send individual messages to a recipient without sharing such details with the intermediary, with the process to look up the right recipient at a postal address to include a round of attempts to verify a name and surname against each salt and verifier saved against a postal address. e. Verifying the ownership and correctness of the details of a legal entity that can own a range of sending divisions, each division to own a set of cryptographic keypair sets, generated at client side, with only the public keys being shared with the intermediary. f. The document/artefact/content sending process which involves the use of an end-to-end encryption data transfer protocol that involves the lookup of the postal address public key sets (which would be enough to send messages to unnamed recipients (i.e. all residents) at a postal address), and, if sending to a named recipient at a postal address, the protocol to involve looking up the individual public key sets of a named recipient without providing such names or surnames to the intermediary, which is possible by trying to verify the name and surname at client side checking against all the salts and verifiers saved by the intermediary against a postal address using a zero-knowledge password authentication scheme; and then using such correctly looked-up public key set(s), as well as the sender's private key sets, at client side, to perform multiple key agreement steps (e.g. using Diffie-Hellman, Extended Triple Diffie-Hellman, Rivest-Shamir-Adleman (RSA) based key agreement schemes) to derive a range of session secrets (to be used for authentication and private recipient's digital signature generation), and other relevant private secrets, which could be only known to the sender and recipient, and then performing a client-side encryption of artefacts, and uploading the encrypted version to an intermediary server in a list indexed by the postal address or a derivation of the postal address (e.g. geocode or geohash) if sending to unnamed recipients, and, to alist indexed by the postal address (or its derivations) and the salt and verifier of the right named recipient, as looked up for sending, and including sender's own postal address and their random identifier, as metadata of the message, to be later on, used to look up the public key sets of the sender for decrypting the message by the recipient. The method providing a zero-knowledge routing mechanism merely based upon owning a postal address and optional name and surname by the sender without revealing the name and surname to the intermediary. g. Sender's digital signature scheme which involves the overall byte list of the message containing all artefacts/documents/contents as well as the name and address of the sender to then be digitally signed using a long-term identity private key, at client side, with the signature being included in the message. The public identity key used for signing will remain on intermediary servers for a long period so that after being changed, they can still be used to verify messages that have not been yet received by recipients and will be in future. h. The document/artefact/content reception process which involves the periodic synchronization of a client-side software system or application or SDKs against a list of encrypted messages, as uploaded by senders, stored on intermediary servers, indexed by the postal address (or its derivations) for unnamed recipients at a postal address, and for named recipients at a postal address, indexed by a random identifier as well as salts and verifiers associated with each recipient's name and surname as per the zero knowledge password authentication protocol, created at client side at the time of registration of a named recipient at the postal address, then looking up the relevant public key sets of the sender, using the postal address of the sender and their random identifier, which are saved as the metadata of the message, and then using the same end-to-end encrypted key exchange protocol at client side, as used by the sender, using recipient's private key sets and sender's public key sets and any ephemeral keys, to derive the same private symmetric encryption keys and other secrets and then decrypting the message and its artefacts at client side and securely storing them, or optionally, re-encrypting them (with random independent-per message keys unknown to the intermediary) and uploading them in an online private bucket for portable cloud-based multi-device access at a later stage, with such random keys being encrypted themselves with keys only known to the recipient and then uploaded with the encrypted messages to the bucket.

2. The systems, methods and cryptosystem of claim 1 wherein the data transfer intermediary maintains zero knowledge of the contents of documents, artefacts, and contents it delivers, as well as, zero knowledge of the name and surnames of recipients and senders, where the intermediary does not maintain names and surnames in any form or shape or hashed or derived formats. 3. The systems, methods and cryptosystem of claim 1 wherein the data transfer intermediary maintains zero knowledge of the names and surnames of senders and recipients but remains able to route messages sent to such names and surnames at different postal addresses. 4. The systems, methods and cryptosystem of claim 1 wherein a recipient can choose to not receive unsolicited messages (e.g. from those senders who do not know the recipient's name and surname despite having access to the recipient's postal address), and, wherein a recipient can choose not to register as a recipient under their name, which leads to their subscription to the postal address in an unnamed fashion to receive all unnamed messages sent to the address. 5. The systems, methods and cryptosystem of claim 1 wherein a sender can request an optional reception acknowledgement which can lead to the generation of recipients' digital signatures against the sender's digital signatures of the original message, all generated based on private keys only known to the sender and recipient, hence protecting the anonymity of the parties involved despite the intermediary's access to public key sets of both senders and recipients. 6. The systems, methods and cryptosystem of claim 1 wherein a recipient who has verified their access to a postal address can be revoked (following an event like moving to a new address or new occupants becoming the new sole subscribers of a postal address) leading to the removal of the old recipients public key sets from the postal address, the regeneration of the keypair set of the postal address between remaining residents and the leaving party becoming unable to receive further messages delivered to the postal address. 7. The systems, methods and cryptosystem of claim 1 wherein any attacker and/or the data transfer intermediary remain unable to add an unauthorized recipient to a postal address to intercept or observe messages sent to that address, as per the reliance of the delivery scheme on private keys only known to the legitimate residents of the postal address.

8. The systems, methods and cryptosystem of claim 1 wherein the intermediary remains able to verify that a sender from a postal address has sent a message to a recipient at another postal address without having knowledge of the names and surnames of the sender and recipient.

105 106 Software Software 111 Development Development 109 107 110 Optional Kit (SDK) Kit (SDK) Channel with Channel with Virtual Printer Libraries, Libraries, Transport Layer Security Transport Layer Security Driver performing performing end-to-end end-to-end 104 1/3

encryption encryption Recipient

101 Sender 107 Data Transfer Intermediary

102 108 103 Sender’s Space Public Internet Network Recipient’s Space

Figure 1. High-Level Logical Building Blocks for Secure Zero-Knowledge Transfer of Documents, Contents and Artefacts