[e-gold-list] Re: AxiomaticTokenizer - Increased payment security with one time tokens

[George Hara]

Patrick,


> First rule of crypto: don't roll your own.

Cryptography has two main technical elements: algorithms and
implementation. The saying above refers to algorithms: "don't roll your
own cryptographic algorithms". In the case I presented, the algorithm
used is SHA256. Custom implementations are what makes any software which
uses cryptographic algorithms.


> Because your salt (you call it a seed) is static

I don't know where you saw that I call it a seed, but I don't call it a
salt exactly because it's static, not random.


> , the "shared secret" is vulnerable to pre-computation attacks.

So is any encrypted data container. Weak passphrases are not the
responsibility of developers, and none of these issues stops
cryptography from existing. (On the details page it's advised to write
down a longer part for the passphrase, and remember a shorter one.)


> This doesn't really matter, because the step of converting to a 
> "shared secret" does not add any further security over just storing the 
> passphrase

On the contrary. A user can use a single passphrase, which is easy to
remember, for different services and accounts, without making it
possible for a single service to access all accounts. This happens
because when the shared secret is generated, it includes the service
name, account name and passphrase. Also, the hash is iterative, which
increases security by forcing an attacker to spend more time at
cracking.


> This will likely be vulnerable to replay attacks, regardless of the 
> presence of a timestamp.  Because the spend token generator is on a 
> disconnected machine, its time will not likely be synched close enough 
> to the payment processor's to have a tight TTL.  Further, because of the 
> transcription time required for the user to copy the token from the 
> screen, the TTL of the message would have to be even wider.

The time stamp is sent in the token, so the service simply needs to
parse the token to extract the timestamp. The service can check the
token a million years later. There is no problem.

It is also explained, on the datails page, how a service can block a
token which was used once: store the timestamp of the last used token.
The next token must have its timestamp bigger, never equal. Since the
timestamp has a one second precision, no user will ever generate two
tokens with the same timestamp. Moreover, even if the service receives a
token with the same timestamp, that is simply ignored.


> This scheme allows, among other things, for ... a MITM.

The same goes for passwords. It's not AxiomaticTokenizer's goal to solve
this issue.

A man-in-the-middle attack requires the attacker to intercept the ENTIRE
shared secret. Spend tokens are immune to this because they are unique
for every single second.


> This could be partially remediated by adding a random nonce, checked for uniqueness over TTL by the payment processor, or by preventing multiple spends in the TTL timespan by the user

These are incredibly expensive and useless mechanisms. Storing the
timestamp of the last used token (and possibly the token itself, for
knowing when to reply with the same response for the same token) solves
all these issues and doesn't increase the size of the token.


> It is probably unwise to use the phrase "one time" with respect to this 
> scheme.

Every single token is a one-time blob of bits. In theory, given the
capability of hashes, there should never be two blobs alike.


> How does the system you use to generate spend tokens get the information
(spend-specific) that it needs to build the token?

Haven't you seen the link to the application written in HTML and
JavaScript?
http://www.gardenerofthoughts.org/ideas/emoney/axiomatictokenizer.htm


> Incidentally, because both of these are symmetric schemes, neither provides for non-repudiation - the payment processor cannot prove that the spend was authorized, as it would be able to in a digital signature approach.

The same goes for passwords. It's not AxiomaticTokenizer's goal to solve
this issue.


>> To protect yourself against such possible events, you always have to
>> send your shared secret from a computer which is free of malicious
>> applications. Since you can never be sure of this, it's possible to
>> split the shared secret in two parts and send each part, to the service,
>> from a different computer. As long as the two parts are not intercepted
>> by a thief and linked together, your money is safe.

> That's a pretty big if.

There are various ways to send the two parts of the shared secret to the
service, like in person or through snail-mail. Devices like CryptoCard
must be configured by banks and are handed in person.


> It also doesn't protect against exploitation of the payment processor

The same goes for passwords. It's not AxiomaticTokenizer's goal to solve
this issue.


> Better way to do it is with a scheme that doesn't require you to reveal
secrets to anyone.

Asymmetric encryption is horrifically complex to implement and manage.
The keys and the signed data must be stored, backup must be performed,
losses and leaks can occur, it's difficult to hide the keys and the
signed data (unlike memorized secrets), the keys must be managed (which
for John Doe is out of the question), and so on.

(Asymmetric encryption will be used by AxiomaticId,
http://www.gardenerofthoughts.org/ideas/axiomaticid/index.htm , but that
is most certainly not going to be used by John Doe.)

Some might say that asymmetric encryption is not really that complex.
Let me make a simple comparison to make my point. AxiomaticTokenizer has
about 30 KB of data When AxiomaticId will be finished, it will be about
100 times bigger, that is, will have about 3 MB of hand-writen source
code. That is 3 millions characters, excluding the numerous rewrites and
staggering design obstacles.

In fact, asymmetric encryption can be implemented in AxiomaticTokenizer
just for the purpose of encrypting the shared secret, which would this
way be protected from interception. This can be done without the user
having to deal with anything known as asymmetric encryption; each
service's public key can be incorporated in the application. The user
would simply have to copy a (much) longer token.

Unfortunately, the SHA256 written in JavaScript is about 10'000 slower
than the one written in native code. I haven't tested any RSA
implementation written in JavaScript, but from this it seems that the
time necessary to encrypt the shared secret with the service's public
key is prohibitive.


---
You are currently subscribed to e-gold-list as: e-gold-list at kobly.com
To unsubscribe send a blank email to leave-e-gold-list-512001C at talk.e-gold.com

Use e-gold's Secure Randomized Keyboard (SRK) when accessing your e-gold account(s) via the web and shopping cart interfaces to help thwart keystroke loggers and common viruses.