asciilifeform: and also entirely symmetric probabilities of flip/nonflip.
asciilifeform: this gives you entirely symmetric probabilities of motion in either direction;
asciilifeform: here is improved scheme : '10' -> 'step left', '01' --> step right, '11' -> flip current and step left; '00' -> flip current and step right.
asciilifeform: btw the '00'--> stop thing is unnecessary and harmful, you stop when you run out of feed tape.
asciilifeform: but it takes up space, and if even 1 of the bits gets flipped (misguessed), you get an avalanche of rubbish.
asciilifeform: so, yes, e.g., '1010101001010101' does ~absolutely~ nothing to the waltz tape
asciilifeform: whole point is to minimize the information conveyed to enemy by knowing about the, e.g., 'To: mircea_popescu' inside; and to maximize the consequences of a misguessed plaintext bit in a cryptoanalysis.
asciilifeform: it has a net effect in that it a) takes up space between non-'neutral' strings b) if enemy misguesses even 1 bit inside it, it becomes quite non-neutral, and cumulatively
asciilifeform: is to take away the algebraic relation.
asciilifeform: sorta was whole point of this notion.
asciilifeform: whereas an arbitrary tape is nonalgebraic.
asciilifeform: yes, it will be long, but of fixed length, and i can picture its structure
asciilifeform: fundamental problem here, is that the operation can be written as an equation
asciilifeform: but i know that the number of passes is related to the payload.
asciilifeform: this cannot be ruled out, because hash -- yes, all of them -- is voodoo.
asciilifeform: say i discover that sha output is 'heavy' on 1s (in the von neumann coin sense) if the input was a sha output of a sha output of a string containing word 'nuke'. etc
asciilifeform: costs you, under some entirely possible scenarios, all of the strength.
asciilifeform: why make them related to the payload.
asciilifeform: but why do you want to constrain the possible tapes thusly
asciilifeform: it is hilarious to watch, from entomologist's chair.
asciilifeform: most of the 'solutions' do not even vaguely pretend to solve the problem, and in fact expertly avoid to say what the problem even might be.
asciilifeform: btw anyone who tries to dig in the 'official' literature re: crypto padding will barf his guts out, the subjects consists ~100% of obscurantist crapola by weight.
asciilifeform: mircea_popescu and others can probably think of some useful and interesting variations on this scheme.
asciilifeform: all that does is to append a few random bytes to the payload.
asciilifeform: mircea_popescu: gpg used PKCS #1 v1.5 (see rfc4880)
asciilifeform: existing padding schemes are precisely what i would like to get away from. idea is to introduce maximal uncertainty re the identity or purpose of any particular bit of unknown plaintext, and max fragility.
asciilifeform: (and i am leaving aside the fact that the use of sha may well introduce structure.)
asciilifeform: mircea_popescu: pretty much all of the extant schemes resolve to some variant of that. the problem is that ~all~ of them introduce structure
asciilifeform: if anyone remembers - plz post link !!
asciilifeform: btw i scoured the l0gz in vain for entire hour, looking for where i promised this, and cannot find.
asciilifeform: that's what 'padding' (terrible misnomer) is. the opposite of errorcode.
asciilifeform: (recall, you want a maximally fragile string. it is quite the opposite of error-correction codes.)
asciilifeform: if it does - then the cost is worth it.
asciilifeform: the problem is that you have to derive a bounding box when you're done and want to turn the playing field into a bitstring for use wherever
