User:Gmaxwell/things im surprised dont exist

Now that we have crypto-currency it's obvious that we are living in the future, — Where is my flying car?

Here are some things which I'm surprised don't exist (at all or beyond research toys)…

• Practical high latency mix networks.
  • All realtime tools like tor an I2P have inherently poor privacy. There are many applications that want privacy (email like uses, bitcoin transactions) which are highly delay tolerant... but there are no modern cryptographic privacy networks that make use of this fact. There is a flooding privacy network (bitmessage) but the design is awkward and flooding only has (at best) strong reviver privacy.

• Usable cryptographic voting tools
  • Okay, the whole lofty goal of replacing public political elections is a big deal and it's not surprising that it's not done... but where are the tools where I and my IRC computer geek friends can use to have an informal secret ballot election to vote someone off the island?

• Usable cryptographic auction tools
  • Like the above though the result is slightly different

• Threshold cryptography ... anywhere except bitcoin
  • E.g. why can't a software team use 3 of 5 gpg signing for its releases? Computers are compromised all over the place (as we've seen demonstrated very well with Bitcoin... without multifactor security is much of our crypto use really snake-oil?

• Encrypted, authenticated, reputable multiparty chat
  • Dear lord, why the @#$@ are we still using IRC?

• Strong steganography
  • The invention of wet paper codes and perturbed quantization, in theory, allow embedding hidden messages in noisy multimedia content in ways which are arbitrarily indistinguishable even to an observer with perfect knoweldge of the encoder (but not the original image or message). The idea is that the image is decoded with a very high rate error correcting code, allowing the sender free choice over what bits they distort to encode their message— and they can use powerful image statistics on higher resolution versions of the image to determine where their distortion will be least detectable. Yet there are no public implementations of the most efficient codes or of embedders with strong statistical models

• High security microprocessor architectures
  • Why does valgrind level tracing exist only in the form of a 10-100x slowdown, why isn't there security more fine grained than NX— things like capability security in hardware? Many applications don't need high performance, using additional transistors to increase security would be a big win— intel MPX is a small move in this direction, but a pretty limited one. (See https://en.wikipedia.org/wiki/Intel_iAPX_432 for an early commercial failure, and http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ for a recent research project.)

• Usage systems languages setup to facilitate formal methods to prevent software being the orgy of fail that it is today
  • There is a little progress here, ATS has strong facilitation for formal methods though its not very usable. Rust achieves a high level of usability, but is only much stronger than C/C++ for memory safety.

• Remote attestation
  • The IBM cryptocards implement a strong functionality where a tamper resistant and detecting computer on a card can run code and produce a certificate chain, traceable to IBM, that gives you pretty good confidence that the code which is claimed to be running on it actually is. This lets mutually distrusting parties have some trustworthy shared computation. Though the security is limited to the (fairly strong tamper resistance) this kind of remote attest has many of the same applications as homemorphic encryption, secure multiparty computation, and program obfuscation with good performance and without a mathematical breakthrough. But the cryptocard is the only product I'm aware of offering this, and I'm not aware of any public service using it. The remote attest efforts around things like Intel TXT appear to be far weaker (and also not widely deployed).

• Non-interactive perfect forward secrecy.
  • With pairing crypto this is trivial, as described using IBE years ago by Adam Back[1]. Generate a master keypair, the pubkey is your pubkey. Generate a private key for each day for a validity interval. Save the private keys. Destroy the old private keys as days pass (bonus: use a smart card to store the keys and expire them for you). Anyone can derrive public key for their chosen read-by date using just your master public key.

• Tools for "robust" cryptography: Cryptosystems fail, the asymmetric systems the public has widely deployed are vulnerable to large quantum computers if they turn out to be constructable and the systems don't fail to more conventional attacks sooner. But it's not a difficult to combine multiple cryptosystems in way which as a strong argument that only one underlying system needs to be strong. Running multiple cryptosystems, esp. sets including QC strong ones may have high bandwidth/cpu overhead but there many are applications where this doesn't matter and long term secrecy may be important— e.g. email. Simple constructions like symmetric key ratchets can results in systems which are secure even in minicrypt[2] if even one message makes it through without being intercepted, and splitting a message N ways to be distributed over multiple channels such that all must be intercepted to decode the message can provide security even if all cryptosystems can be broken (well, assuming the users have true random number generators).