In some embodiments, in order to verify that the recovery escrow service 230 holds the recovery private key 205, the at least one first computing device 210 periodically (e.g., monthly) sends a recovery message, such as a random string of text, for storage at the recovery escrow service 230. For example, the recovery message may be sent via SSH-FTP interface with a lambda function retrieved for instance from an API of a news site (e.g., such as the “New-York Times”) in order to show a publicly verifiable time stamp. The recovery escrow service 230 may sign the received recovery message with the recovery private key 205 and accordingly send a report including the signed message (e.g., a signed string) to the trustee 330. The recovery message, such as a random string of text, may be any random message and therefore not a secret so that sending the recovery message may be carried out by regular (non-secret) methods, for instance send the message via mail.

The trustee 330 may publish the report with the signed message in the repository 240. Thus, any user of the system may use the at least one second computing device 220 to retrieve the report from repository 240 (e.g., from ‘GitHub’) in order to verify that recovery escrow service 230 indeed holds the recovery private key 205, for instance compatible to the recovery public key 204 already stored at the at least one second computing device 220.

In some embodiments, the at least one second computing device 220 is connected to the computer network 201 and a transaction is added to a ledger of the computer network 201, in accordance with the received signed at least a portion of the cryptographic key 206, for instance as in a cryptographic wallet.