Update of "Experiment: mmmv_symsig_t1"
Not logged in
Overview

Artifact ID: a589c629c83642706ea620b142f8e5018dfa42d7
Page Name:Experiment: mmmv_symsig_t1
Date: 2017-10-10 01:35:30
Original User: martin_vahi
Parent: 6f259b3a8c6a873487b19030fae5e5e697b41ed1 (diff)
Next 8639e097dc0449ee79c54fcb0a2c9a44824f58c9
Content

Currently the mmmv_symsig_t1 lacks any code.

The mmmv_symsig_t1 wraps symmetric key encryption command line tools and implements a signing system, where parties, who have never met directly for a key exchange can probabilistically authenticate each other. The feasibility of using one-time-pads or one-time-pad like ciphers is based on the fact that a year 2017 price for 1GiB of USB-stick based flash memory costs about 1€. With the exception of metadata related security issues, one-time-pad like ciphers tend to eliminate security flaws at the encryption algorithm side.

It's worth to note that if both keys of a public encryption algorithm are bundled together and the whole pair is kept secret the way  symmetric keys are kept secret, then public key encryption algorithms can be used as symmetric key encryption algorithms. That allows the "standard" tools like the GNU Privacy Guard to be used in the role of the symmetric key encryption algorithm implementation.


The Scheme

End users(hereafter: EnU), including the Bob and the Alice, individually meet with a key exchange service provider (hereafter: KXS). The KXS gives each EnU multiple GiB worth of symmetric keys that are shared only between the KXS and the EnU. If the EnUs have not met with each other for a key exchange, then the KXS forms a central hub that decrypts the ciphertext of one EnU and encrypts the cleartext for another EnU. That is to say, if the Bob and the Alice use only a single KXS, then the KXS acts like the Eve, when the Eve conducts a man-in-the-middle attack. To probabilistically counter the man-in-the-middle attack, the Bob and the Alice use the services of multiple KXS to agree a set of temporary encryption keys, one temporary key per one KXS. The Bob and the Alice use the temporary keys for onion-encrypting the actual data exchange between themselves. If at least 2 KXS-es manage to keep the keys that they use for communicating with the Alice and with the Bob a secret and those same 2 KXS choose to keep the overheard temporary keys a secret, then absolutely no KXS is able to decrypt the Bob's and the Alice's onionencrypted session.




Optional Improvement Opportunities

In addition to the temporary keys that were overheard by the KXS, the Bob and the Alice may use additional temporary keys that they negotiated during previous sessions. During the session that is held through the eavesdropping KXS the Alice should generate halve of the temporary key and the Bob should generate the other halve.



Beneficial side Effects 

The more KXSs there are, the more break-ins have to be conducted to get all the keys that the Alice and the Bob use for communicating with the KXSs. If all of the sessions between the KXSs and their users are decrypted by eavesdroppers other than the KXSs themselves, then an increase of the number of KXSs increases the number of sessions that the non-KXS-eavesdroppers have to listen in, which in turn increases the number of different geographical locations, where the non-KXS-eavesdroppers need to place their probes. If the KXSs reside at different "jurisdictions" that happen to be enemies, for example, China, Russia, EU, United States, Latin America regions, Arabic dictatorships, etc. then the lack of intelligence sharing between those "jurisdictions" partly protects the Alice-Bob onionencrypted session from absolutely everybody, except the session related metadata, but the metadata can be "salted" by using temporary keys from previous onionencrypted sessions and by choosing the KXSs  randomly for every onionencrypted session. The more KXSs there are, the greater the number of different operating systems and hardware the set of KXSs uses. The greater the variety of operating systems and hardware that the KXSs use, the more elaborate must be the software that is needed for breaking into KXSs systems. Some extra variety within the KXSs can be introduced relatively cheaply by using FPGA based embedded boards

For high security setups the KXSs core functionality might be implemented as a microcontroller board that does all the encryption and decryption and stores all of the keys at an USB flash drive that is directly connected to the microcontroller board. The microcontroller board can be connected to the internet through GPIO of some Raspberry Pi like computer, which acts as a "network card with all internet communication related software included". Since the microcontroller software is remarkably primitive, then there's practically no attack surface there and the best that any remote adversary can do is to break into the Raspberry Pi, but the Raspberry Pi acts only as a fancy network card and resides outside of the secure zone. Different KXSs can use different encryption algorithms for communicating with the Alice and the Bob. That allows the use of encryption algorithms that are usable on the microcontroller board. The microcontroller software is probably small enough to allow it to be fully formally verified. As specifications and real hardware can differ, testing is relevant even after formal verification. To reduce the number of untested states, the microcontroller board can have a dedicated microcontroller for enforcing power resets that happen not less than X times per 10 minutes, preferably at the end of each KXSs session.



Who Might want to use such a System

Only freelancers and privacy advocates. 

Megacorporations  want to spy on their salary slaves, generally known as "employees", and this system, if properly implemented and used, prevents the spying. Banks that use checks in stead of pin calculators in 2017 certainly could not care less about securing their IT-systems and business processes. Medical institutions resort to comfort, because according to them the "public key cryptography works just fine" and many hospitals have pretty crappy IT-support to start with, not to mention the fact that doctors and nurses would rather do their real work, wear bloody gloves, than do computerized "paperwork".