Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Workspace / Minutes for crypto meeting, Feb 1st 2008

Minutes for crypto meeting, Feb 1st 2008

The minutes for the meeting

Kenny, Alex, Nils and Joerg are attending. The meeting starts at 10.30

results so far

The crypto experts have been:

  • analysing existing schemes
  • looking at the future extensions
  • looking at  formal definitions, what is the formal language
  •  chaum 82 and chaum 88 schemes
  •  old protocols in the light of new security notions
    •  are the modern security notations work for our model
    •  only lately did formal formal specification of requirements happen
      see the  05 paper?
  • code examination (this was mentioned, and discussed more closely towards the end of the meeting

 

Protocol review

 

We then went on to have a closer look at our protocoll, and discuss different aspects of it, in the light of the ongoing technical development and legal research. This took up most of the day.

 

  • opencoin seems to implement "cut and choose"
  • discussion on how to best store secret keys - e.g. using concrete for the mint computer
  • serial obfuscation has to removed, dsdb keys have to removed - this 'extra' step does not bring too much gain in security
  • Discussion of the problem of randomness - serial numbers and random factors. We need to comment more on this in the source code
  • Discussion of transaction ids. They seemed to be problematic in the beginning, but turned out to be a useful 'extension', e.g. in the light of our delayed minting process
  • The 'target' for our redeem/mint requests  might be an easy attack target. Some discussion whether we can authenticate the use of the target. As we don't have ids for our clients that might be a bit hard to do. The approach to use seems to use one-time prepaid target ids, e.g. buy a voucher at a hub, pay with a 'xyz123' subject via bank transfer.
  • We might need to split transfer_token_request into three different requests. Quite an intensive discussion whether we should keep it in one or split it up.One of the reasons is to be more explicit. One approach could also be to use a transaction_type in the options parameter.
  • Discussion of our use of error messages - some of them give extra information to an attacker. Some can be kept (like the 500 internal error messages). We should especially not explain why a decryption/verify did not work. We need to go back and check the messages.
  • Reseting the protocol - if an error occours it might be a good idea to start all over with a protocol, instead of resuming at a state.
  • Emphasis on the key seperation - minting keys can only be used for minting, for nothing else. But as we have seperate keys for IS and mint anyhow, we are doing quite fine here.
  • We might have potential DoS attack when signing a (huge) stack of coins in a non JIT way - the attacker could e.g. have 10000 coins minted, and asks repeatedly for them using a transaction id, using a botnetwork. This aks for an upper limit for the length of list of coins
  • Another attack is when a mint signs blinds, but the attacker blocks the transaction_accept, instead sends transaction_reject. this way the client will have to assume that the coins where never minted, leaving the coins at the mint.
  • We need to be stronger on our requirement ot have an integrity encrypted tunnel. In our case SSL might suffice, if the clients actually check the IS server certificate. We have the problem though of non identity protected wallet-wallet transfers.
  • We need to make sure that error messages are also transfered using this tunnel
  • p2p + no identity -> man in the middle problem...
  • New concept of encrypting coin to issuer in online scenario. This is basically following Mathews idea.
    This is for wallet to wallet transfers
    • A encrypts coins to the IS
    • A sends encrypted coins and cleartext sum of coins
    • B passed coins to IS, requesting either exchange or redemption
    • IS either exchanges, redeems or rejects
  • This way we avoid the attack where B gets the coins, creates identical ones (Mathews chained attack), and creates a double spending situation
  • This approach seems to be superior to sending the blanks of coins before sending the coins. Even though it might feel (emotionally to the user) like a secure thing to do, its not
  • Big discussion of the 'fair-exchange' problem. We basically have no easy way of getting around the problem of B ripping of A by accepting coins but not delivering. We can not create a useful countermeasure without introducing PKI to the system (so it seems).
  • This is also due to the initial design of Chaums protocoll - the merchant is always trusted
  • To some extend we have some form of id in ssl, but thats outside of our protocol

 

Code review

 

We spend a short time looking at our code.

json seems to an acceptable format for information exchange, without any major drawbacks

Nils points out that we need to make sure that once we signed json, we never reconstruct it, but cary it along in our coins (or use it to transfer the coins). This way we accept the problems of slightly encoding coins differently, which risks validation of coin signature

The rsa.py was accidently reviewed, even though this was just some playground for Joerg. We need to make sure to mark whats meant seriously and what not

The code in rsa.py is in parts highly ineffective and carries security problems. Especially the chunking of messages is very much 1970s style, and should be avoided. Instead we should use

  • RSA-OAEP for small messages
  • RSA-KEM + a DEM for large messages / encrypt-and-MAC-AES-CBC

 

Overall impression

 

Besides the obvious funny bits of the rsa.py the protocol did not seem to contain major flaws that would have the experts lying loughing on the floor. So far we seem to be headed the right way

 

Next steps

 

  • We need to factor in the comments by the experts
  • The crypto experts will have another 4-6 days in February to work on our system. We agree to have the output on the mailing list, and there might also be a small report towards the end. They will also try to look into our questions about possible extensions, and try to estimate the cost of implementing those (on a crypto level).
  • We might need to have another meeting

 

Appendix: Possible protocol extensions

 

  • recovery of legal coins after minting key exposure
  • receipts
  • revocable anonymity
  • fair exchange
  • distributed (threshold-) minting
  • (D)DoS resistance

 

Add comment

You can add a comment by filling out the form below. Plain text formatting. Comments are moderated.

Question: open.....
Your answer: