For those with interest in the underlying technology, we will over time produce more content describing the technology approaches we are using in detail. Here is a basic summary of the technology approach we have used in the implementation of the digi.cash system:
• The basic payment protocols are based on the Blind Signature Systems as described by David Chaum in his 1982 research paper.
• Further coin creation and communication protocols are largely based on the approach published in 1998 by B. Schoenmakers as 'Security Aspects of the Ecash Payment System' (Volume 1528 ofLecture Notes in Computer Science, Springer Verlag, Berlin, 1998).
• Some significant changes and additions to the approach outlined in the above paper have however been made.
To those with interest in payment privacy, the most important difference in our system is the operational choice we made to auto-generate and retain recovery strings. The recovery string is essentially the seed used to initialise the random number generator in the digi.cash wallet. It determines the 'serial numbers' of the electronic banknotes that this wallet will create. It is also the key to our recovery function, that is our ability to recover and re-create digi.cash that has been lost with a lost or stolen phone. Those versed in cryptography will immediately recognise that this recovery key is also in itself a security and privacy risk. Combined with username and password, it would essentially allow an intruder to 'recover' and thus steal valid electronic coins. It would also allow the server to create full records of all transactions of an individual wallet. In operational practice, we keep the recovery seeds in encrypted form in an offline storage facility, thus guaranteeing that a process of manual intervention with various escalation and authentication steps is required for a recovery key to be used. But it also makes recovery an 'expensive' process. For payment privacy, you could therefore say that in our current implementation, payer privacy is operationally assured, but not mathematically assured, despite the fact that blind signature technology can in principle achieve the latter.
The choice of this approach itself was a balancing act, as you can appreciate, and we may offer different options for the handling of the recovery string in future, in jurisdictions where that is permissible. But we made the choice for the following reasons:
• Use of a recovery string is what permits the recovery of digi.cash from lost devices – a major concern in our user research. So not providing this function at all was not an option.
• Giving full control of the recovery string to the user creates an increased security risk, so we did not want to offer this option at this stage. It could be an option for 'informed/expert users' at a later stage.
• Having access to the full transaction record, if only as a manual exception, is a requirement to us operating in some legislations, such as the EU. Here, access to full transaction records is currently an explicitly mandated requirement for any electronic payments.
So, for full payment privacy advocates, while we may not provide exactly what you want, at least we have clearly stated what it is that you get...