Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>So here's my suggestion, if you want to solve this using encryption...</p> <ul> <li>Each user <em>and</em> each company should generate <a href="http://openpgp.com" rel="noreferrer">OpenPGP</a> (or <a href="http://gnupg.org" rel="noreferrer">GnuPG</a>) <a href="http://en.wikipedia.org/wiki/Public-key_cryptography" rel="noreferrer">asymmetric</a> public/private key pairs</li> <li>Each of those public keys should be uploaded to a <a href="http://en.wikipedia.org/wiki/Key_server_%28cryptographic%29" rel="noreferrer">public key server</a></li> <li>Companies could optionally "<a href="http://en.wikipedia.org/wiki/Digital_signature" rel="noreferrer">sign</a>" the public keys of the individual users, to designate a trust relationship with those users (and revoke that signature if that relationship changes)</li> <li>The auctioneer or non-partisan arbiter would also generate a key pair and push that public key to the public key server</li> <li>As part of an auction registration process, each user would import the public key of the auctioneer, and the auctioneer would import the public key of each user</li> <li>A trusted third party, perhaps a <a href="http://en.wikipedia.org/wiki/Software_as_a_service" rel="noreferrer">SaaS</a> vendor outside of the auctioneer, would host a service through which users and the auctioneer would communicate</li> <li>Bidding users would create a bid by <ul> <li>signing their bid with their private key</li> <li>encrypting their proposed price to <em>two</em> keys: their own public key <em>and</em> the auctioneer's public key</li> <li>submitting their bid to the trusted third party service, which would need to enforce an embargo on any user retrieving bids before the auction expiration</li> </ul></li> <li>At auction end, and <em>only</em> after auction end, the auctioneer retrieves all of the bids, decrypts them, and verifies signatures</li> </ul> <p>A couple of key points:</p> <ul> <li>It's essential that no user or company private keys are ever shared or stored within the service -- that's the only real "flaw" I see in your proposed methodology in your question. If that's the case, it would be very possible for one user to accuse an administrator of "fraud" or "tampering" with bids, as an administrator of your server would ultimately have access to the private keys of all users, since you've generated them yourself.</li> <li>Along those same lines, it's essential that any an all communication and "bids" are cryptographically "signed" with the <em>truly</em> private keys by each user. This is how you would know that a bid came from one particular user and <em>only</em> that user, and that the bid could not have been tampered with.</li> <li>Encrypting the bids to the public keys of the bidding user and the auctioneer ensures that the third party SaaS vendor has no introspection into the bids themselves during the blackout period while the auction is open. I believe this is the most important point to solving your problem as described.</li> <li>Note that it might actually be preferred to encrypt each bid to a ring of <em>all</em> of the bidding users, if by design you want to make all bids public after the auction is closed. That would be a slight modification to my algorithm as described above.</li> </ul> <p>In the interest of full disclosure and perhaps some subtle marketing, I happen to be the architect and CTO of a company called <a href="http://gazzang.com" rel="noreferrer">Gazzang</a> who has implemented a product called <a href="http://gazzang.com/products/ztrustee" rel="noreferrer">zTrustee</a> which operates exactly as described above ;-)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload