We all know that Open Source was to free ideas from incarceration, not deprive programmers of income. Here is a rudimentary “OpenDRM” scheme.
Step 1 (Python script)
Step 2 (Python script) – one possible “salt3″ might be a message digest of the object code itself. This would allow updated versions to be remunerated supplementally.
example database (as pictured above)
Digital work product can be intercepted online, and distributed without the permission of either an employer or employee. To limit problems due to intercepted work product, here is an experimental protocol.
- Prepare an anonymous email account to receive the work.
- agree by contract what the work will be, and how much the compensation will be.
- contractor does the coding, computer aided drafting or other tech work product, encrypts it, and emails encrypted product to the anonymous email address. (If processing is the service, such as 3-d rendering, an encrypted DVD-R would serve the purpose.)
- employer receives email, and pays the agreed price.
- contractor releases the password (verbally) to the employer, who is authorized by payment.
The protocol above provides for internet transmission of work that is otherwise accomplished offline, to avoid “phone-home” viruses.
This does not guarantee the code will be as agreed in quality, but the reputation of the contractor will be important to his future job prospects.
The payment can be by check or wire transfer. Charlatans hate bank account numbers because the penalty for false ID at a banking institution is severe.
The reason to receive the work at an anonymous email is that the IP address of a base location can be tapped by competitors, who may wish to monitor or limit the progress of the employer. An anonymous email can be checked at an internet cafe or a library. If only encrypted data comes in there, little can be lost until it is decrypted.
This does not guarantee that a programmer might not keep backup copies of his work. The copyright implications may make this more or less desirable in various contexts.
Encrypt as needed, provide passwords later. 7-zip and WinRar compression applications both support AES encryption, and Truecrypt containers are available for more experienced users. The Variety of sturdy encryption algorithms works to the detriment of attackers.
Most DSL or Cable modem solutions employ a device called a “Residential Gateway,” that converts a transmission signal to a Local Area Network signal. Since most routers can clone the MAC address of a Network Interface Controller, it might be natural to want to more securely “lock down,” the implementation using MAC address filtering.
A superior setup might see the Gateway turning on MAC address filtering, with exactly one Media Access Control address, and that address chosen at random, not off the network.
Then, the router (downstream of the Gateway) is instructed to present or “clone” that particular MAC. As such, the Gateway now believes that the router is the only authorized device on the network.
Internally, the router is then instructed with a white list, to recognize only the MAC’s of authorized machines. Note: most routers list Hardwired MAC’s and Wireless MAC’s separately.
In a home network situation, this would not be as friendly to guests, as one might want to be, but it would be completely secure against external browsing. The “gold standard” for security is that it should be impossible to compromise without physical access.
Cap it off by instructing the Gateway not to reply to pings, and your network can be both unobtrusive and secure against anyone without physical access.
Vigenere only works if you implement the plaintext/password in a row/column order. If you reverse it, so you look up the password vertically (using it to choose the row,) and the plaintext horizontally (using it to choose the column) then the result is a hash – it is deterministic, but it cannot be reversed by the same or any other password.
To salt the hash, re-arrange the alphabet, and maintain the requirement that the row and column labels (index) retain the order of the transposition. Despite the intuitive expectation that messages encrypted with the same password would not change, they do so. Different salts result in different cipher-text of the same message using the same password.
Note: Although it is indeed a hash, this does not rule out “collisions,” and it is more of a novelty than a cryptographic tool. Nevertheless, it makes an excellent illustration for students of the field.
Simon Singh demonstrated a lossless Vigenere in his book, “The Code Book.” I learned it differently in my youth, under the moniker “Rogue’s Gallery.”
This (symmetric) Vigenere is “lossy,” and replaces lost information with the character “z.” The placement of the “z’s” is password dependent, so encrypting and decrypting with one password, and then performing the same operation with a different password, illustrates the principle of a password dependent watermark.
Holograms are famously hard to duplicate. Here is a scheme to use a hologram in an ID card.
- Using film, make a hologram of the employee’s bust, with company logo in the shot.
- Make an ordinary color photo as well.
- Embed the holographic negative in the ID (possibly laminating it.)
- On the card, print the photo, the name, employee number, corporate logo etc.
- 3-D bar code a salted hash of the data, salted with salt “K”
To verify the ID, the gate-keeper must:
- Visually compare the photograph to the individual
- Using a laser pointer, or possibly a grocery store type mirror based LED projector, view the hologram, comparing it to BOTH the individual AND the photograph.
- Type ALL identifying data into a computer form, which performs a salted hash (salted with salt “P”) of the data, and performs an RSA signature associated with the authorized access point.
- Scan 3-D bar code hash.
- Using the Corporate RSA Public key, send signed info to escrow system for authentication.
- At key escrow system compare “P” salted hash to record of authorized users, and ensure that “K” salted hash also hashes to the correct “P” salted second value (hashing the hash.) This ensures that dummy employee numbers etc, are compared in two ways.
- Receive (in this example) authorization #, time and date stamped, RSA encrypted with public key of the authorized access point.
- De-crypt and authorize to proceed.
While this might seem cumbersome, it would be very difficult to deceive. It would also accommodate environments in which the gate-keeper did not recognize the employee personally. It would be somewhat slow, and it might be possible to improve it without compromise – this is a nascent idea.
The IDEA cipher was subject to an attack more efficient than brute force, in 2012.
Despite this, competent researchers still agree that the attack is not yet computationally feasible. If you’re a little nervous, here’s a way to harden your IDEA implementation.
Block ciphers are hard to parallelize in, for example, CBC mode, because the input for the n’th block is dependent on the n-1′th block. A quick solution to this, is to divide the plaintext into four interleaved groups, such that the first, fifth and every fourth block thereafter, is in one stream, the second, sixth and every fourth block thereafter is in the second stream, the third, seventh and every fourth block thereafter in the third stream, and the fourth, eighth and every fourth block thereafter is in the fourth and final stream [Applied Cryptography, Chapter 10.] In this way, an attacker must compromise enough streams to interpolate any data he does not have.
The crucial factor is that the initialization vectors of each stream MUST be INDEPENDENT of each other. Here is a way to obtain four such independent initialization vectors.
- md5sum the password (if the password itself is too small, the issue is moot)
- Take the right-most 8 bits as an integer (0 to 255) “n.”
- add 1
- sha512sum the (unmodified) password n times (hashing the result successively)
- take the first 128 bits as vector 1, the second 128 bits as vector 2, etc.
- This result is deterministic, and can be completed identically by both sender and receiver.
IDEA has a 128 bit keyspace. Apply such procedures as are necessary to exclude weak keys, and then encrypt each stream with the relevant initialization vector, interleaving them again, as you go.