Cut an encrypted message into thin electronic slices

Notice: If you are a nerd or computer expert, think twice before you read this. May cause distress to experts. We take no responsibility for adverse mental or physical effects.

Remember these old black and white movies in which some kind of matching piece of jewelry proves that the two heroes are siblings separated at birth?

Or the Western with the dollar bill torn in half?

Hey, even the myth of Excalibur, King Arthur's sword, could be cited as an example, a far fetched one alright, but still.

In reality, the idea for this post comes from reading about various efforts to develop machines that can undo shredded paper. In Germany, they have made tremendous progress in re-assembling torn up Stasi documents.

Paper shredders for businesses now offer cross shredding into more than one bin in addition to ever more refined cutting tech.

How about using a reversible shredding approach for digital messages?

Here is how it could work:
1) Encrypt with PGP, using the ASCII armor output option.
2) Cut into two digital equivalents of slices, for example like so*:

mQENBEpWTPIBCAC3bXBy

Slice 1

mEBpTICCbBy

Slice 2

QNEEWTPICCbB

Slice 1 has the odd characters, 1, 3, 5, etc., add PGP header & footer to each**
Slice 2 has the even ones, 2, 4, 6, etc., add PGP header & footer to each

3) Send out Slice 1
4) Send out Slice 2
5) At the final recipient, reconstitute, decrypt, enjoy.

This method will prevent your message from being grabbed on the wire in a single packet re-assembly operation. An adversary who has the decryption key, will need to get hold of all [TBD: it that correct?] slices (at least for now) and merge them into the right order before decryption will yield a useable message.

There are multiple ways to decide on slices, we just picked the easiest one, and even for that you need to make sure the recipient uses the same base [dig - old VB coders].
As long as the sender and the recipient know how the slices are made, putting them back together may require little programming and works like a charm.

You could, for example, use a password to decide on slicing if you prefer easy linear slicing. For example, a trivial "ab" in a nicely encrypted message to mean even and odd. Or you could use a column/array approach because ascii armor will produce a nice column output.

And since you are looking at a matrix, be my guest and do something cool with it.

For the more critical readers:
Yes, deep packet inspection is a bitch. But the beauty of the internet is that you have choices. Who says that you must use the regular email protocol to get a message from Bob to Alice?
With a little bit of automation, you can work wonders. Maybe Charlie doesn't mind to be a relay, may you have friends who can do a couple of TOR hidden services.

Unless you are under active surveillance anyway, the simple act of slicing a message will lead to the following result in the database of the bad guys (which, of course, would be China or Russia).

Record 1:
On October 18 2014 at whatever time UTC, there is a message from Bob to Alice:

mEBpTICCbBy

Record 2:
On October 18 2014 at whatever time UTC + a few minutes, there is a different message from Bob to Alice:

QNEEWTPICCbB

If the bad guys want to brute force this in a year or two, good luck. Unlike paper slices, such digital slices have no physical edges, no ink marks that can be matched up. To the computer the slices look like valid messages in their own right.

And, you are the experts, so think of something.

Disclaimer:
Of course, if you use any of the above modifications to standard communication outside of a class on How not to do Encryption, we take no responsibility.

One more thing:
If you write a practical piece of code, tell us.

* For the nerds: This is the very first manual illustration, we might not have the counting sequence right.

** Or do not add them -- depending on your needs.