Vulnerabilities

Since it's important to keep all the potential vulnerabilities in the forefront, this page will help us keep track of those.

Transaction server might inflate the currency

Solution: An auditing protocol must be utilized, either by the issuer directly, or by the other members of the voting pool.

Vulnerabilities in C++ code

An attacker could potentially buffer-overflow the C++ code and gain access to execute their own code.

Solutions:

• Static and dynamic analysis. Some of this has already been done -- more must be done.
  
• Security audit of C++ code.
  
• Data validation in C++ code.
  
• Test scripts for data validation.
  
• Penetration testing.
  

Attacker might intercept a message and send it twice (Re-play attacks)

Solution: Each message contains a "request number" which must increment with each message. This prevents re-play attacks.

Issuer holding gold might lie about the physical gold

Solutions:

• A physical audit of the issuer's physical gold is the only way to make sure he actually has the gold.
  
• A basket currency on OT allows each Nym to distribute the risk of a currency across multiple issuers.

Issuer holding Bitcoins might lie about the actual Bitcoins

Solutions:

• Bitcoins on the blockchain can be audited by any observer. (This is an advantage that Bitcoin has against physical gold.)
  
• Store the BTC in a voting pool, so that there is no longer any "issuer" who must be trusted. (Though the pool itself must be trusted.)