Raph Levien writes:
On an unrelated topic... cypherpunks like to count bits, right? What is the correct number of pseudorandom bits to use in a MIME multipart separator? If the data has a line which matches the separator, the message is corrupted. Of course, if you can take multiple passes through the data, you can simply verify that it does
No need !
not contain a line which matches the separator. But if you're restricted to a single pass, then the only way to do it is to use a randomly generated separator. I've waited a bit, but as nobody seem to have pointed out, you can definitly find a unique stream in a *single* pass (but maybe what you really want is no pass at all ?) {you add a new random byte each time you find your sequence in the stream, and goes forward (as the previous separator was not in the "past" of the stream, you don't need to go back)}
What am I missing ? (anyway, see below) (I hope my answer is not as clueless as the "A-dice anonymous" one)
I figure that 128 bits should _definitely_ be enough (that's what is in the new premail code now). Even 64 bits should ensure that it is unlikely that anyone will ever experience message corruption over the expected lifetime of premail. However, it makes me nervous. What do people think?
Isn't PGP encoded stream containing only base64 chars ? Why not use "====PGP part #====" (as you can't have more than 2 = in a base 64, and only at the end anyway) or "@PGP part #" or whatever starting with a non base64 char ? so "@" = 8 bits is my anwser, do I win ;-) ? dl -- Laurent Demailly * http://hplyot.obspm.fr/~dl/ * Linux|PGP|Gnu|Tcl|... Freedom Prime#1: cent cinq mille cent cinq milliards cent cinq mille cent soixante sept Greenpeace Uzi NORAD DES NSA [Hello to all my fans in domestic surveillance] Clinton