Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

implementation of one-time-pad with Mersenne Twister PRNG

549 views
Skip to first unread message

bystander

unread,
Jun 29, 2011, 12:27:46 PM6/29/11
to
This is probably a very naive idea, but if a one-time-pad was
implemented in code using a high-quality PRNG such as the Mersenne
Twister, would it be cryptographically strong?

Jacob

rossum

unread,
Jun 29, 2011, 2:24:27 PM6/29/11
to

It would not be a One Time Pad. You *cannot* use a generated key with
a OTP. In order to be a One Time Pad the key must be as long as the
message and truly random.

A Mersenne Twister has a key of limited length. Hence it cannot be a
OTP for messages longer than that length. Look up "unicity distance".

What you are describing is a stream cypher. A pseudo-random keyed
keystream replaces the true random key in a OTP. Stream cyphers can
be very effective and useful. They are of more practical use than the
OTP. But they do not meet the security requirement of a OTP so they
are not provably unbreakable.

rossum

kg

unread,
Jun 29, 2011, 3:10:39 PM6/29/11
to

Such a stream cipher (not one-time-pad) is secure if the pseudo-random
generator is secure. The Mersenne Twister is not secure.

--
kg

Greg Rose

unread,
Jun 29, 2011, 9:31:36 PM6/29/11
to
In article <iuftbf$8sk$1...@orkan.itea.ntnu.no>,

Not only that, but it's also impractical... the
state of the generator is huge, so key management
is almost as bad as the real thing, without the
benefit of actual security!

Greg.
--

bystander

unread,
Jul 2, 2011, 5:13:58 PM7/2/11
to
On Jun 29, 3:10 pm, kg <kristiag+n...@math.ntnu.no> wrote:

I agree that no PRNG is "secure" in the sense that it is theoretically
unbreakable but I believe that sequences generated by the MT have been
shown to have all the statistical properties of "true" randomness. For
example, sufficiently large samples pass all the Diehard tests for
randomness. Obviously, the OTP is only as strong as the method used
for generating the pad. In David Kahn's book he states that the
Soviets generated their OTPs by having clerks type "randomly" on
typewriter keyboards! Surely, the MT is as secure as that. Soviet OTP
encryption was broken but only because some pads were used more than
once.

It seems to me that the distinction between a stream cipher and a OTP
is tenuous at best. In practice, they both accomplish the same thing:
producing a key as long as the message itself. The period of the MT is
2^19937 - 1, long enough for any practical message.

Thanks to all for your replies to my post.

Jacob

Maaartin G

unread,
Jul 2, 2011, 6:44:58 PM7/2/11
to
On Saturday, July 2, 2011 11:13:58 PM UTC+2, bystander wrote:
> I agree that no PRNG is "secure" in the sense that it is theoretically
> unbreakable but I believe that sequences generated by the MT have been
> shown to have all the statistical properties of "true" randomness.

I can't tell if this is true, but I'm sure that it's not enough.

> For
> example, sufficiently large samples pass all the Diehard tests for
> randomness. Obviously, the OTP is only as strong as the method used
> for generating the pad.

Again: DO NOT CALL IT OTP. It is a stream cipher.

> In David Kahn's book he states that the
> Soviets generated their OTPs by having clerks type "randomly" on
> typewriter keyboards! Surely, the MT is as secure as that. Soviet OTP
> encryption was broken but only because some pads were used more than
> once.

The so called "two times pad" is really a terrible cipher. :D

> It seems to me that the distinction between a stream cipher and a OTP
> is tenuous at best. In practice, they both accomplish the same thing:
> producing a key as long as the message itself.

They're similar, but the distinction is not tenuous at all:
- The OTP requires a key as long as the message, stream ciphers do not.
- The OTP is unbreakable in every sense you can imagine, stream ciphers are not.
- The OTP is terribly impractical, stream ciphers are not.

> The period of the MT is
> 2^19937 - 1, long enough for any practical message.

A period of 2**64 would also suffice for most practical reasons, a period of 2**256 would suffice until the sun goes out. But the period length itself in that important. AFAIK seeing as much output of the MT as its internal state allows you to reconstruct the state easily, so it's quite insecure.

See RC4 for an obsolete, but very simple stream cipher. See Salsa20 for a modern and yet unbroken one. Both are simpler and more practical than MT.

Scott Fluhrer

unread,
Jul 2, 2011, 8:30:30 PM7/2/11
to

"bystander" <ethic...@hotmail.com> wrote in message
news:8aa48443-a74b-4737...@u28g2000yqf.googlegroups.com...

> On Jun 29, 3:10 pm, kg <kristiag+n...@math.ntnu.no> wrote:
>> bystander <ethicalb...@hotmail.com> wrote:
>> >This is probably a very naive idea, but if a one-time-pad was
>> >implemented in code using a high-quality PRNG such as the Mersenne
>> >Twister, would it be cryptographically strong?
>>
>> Such a stream cipher (not one-time-pad) is secure if the pseudo-random
>> generator is secure. The Mersenne Twister is not secure.
>>
>> --
>> kg
>
> I agree that no PRNG is "secure" in the sense that it is theoretically
> unbreakable but I believe that sequences generated by the MT have been
> shown to have all the statistical properties of "true" randomness.

Possibly true, but totally irrelevant. To be a cryptographically securet
PRNG, it is not sufficient to pass a set of commonly accepted statistical
tests (such as Diehard), it is necessary to pass tests designed with
knowledge of the PRNG internals. For example, an attacker may be able to
look at the first 2496 bytes (624 words) of MT output, invert the tempering
function for each word, and recover the MT internal state. He can then run
the MT forward, and predict further outputs; this test can be used both to
distinguish the MT from a random function (by comparing the expected further
outputs with what is actually given), and is in practice a total break of
security.

Actually, you can do even better than this. All operations within MT are
linear, and hence the internal state can be recovered with just about any
19968 output bits (plus a few extra, in case some of the original output
bits aren't linearly independent).

Now, doing this 'inverting the tempering function and then running the MT
generating/tempering on the recovered internal state' is obviously not a
general purpose statistical test; just about nothing other than the MT would
fail it. That doesn't matter; this nonstatistical attack is sufficient to
show that the MT is not a cryptographically securet PRNG.

> For
> example, sufficiently large samples pass all the Diehard tests for
> randomness. Obviously, the OTP is only as strong as the method used
> for generating the pad. In David Kahn's book he states that the
> Soviets generated their OTPs by having clerks type "randomly" on
> typewriter keyboards! Surely, the MT is as secure as that. Soviet OTP

Actually, that is not true (and don't call me Shirley). As above, I've
given a practical method of breaking an MT-based cipher using a modest
amount of known plaintext; in contrast, the Soviet's OTP wasn't actually
broken until they were used as "two time pads". In this case, the reason is
that the clerks (and humans in general) are fairly bad at maintaining long
term correlations; computers are quite good at it. The Soviet pads had
plenty of short term correlations (which the NSA was well aware of);
however, the key they struck at position X had no strong correlation with
the key at (say) position X+2496; streams generated by computer algorithms
often have such correlations.

> encryption was broken but only because some pads were used more than
> once.
>
> It seems to me that the distinction between a stream cipher and a OTP
> is tenuous at best.

Actually, there is a fairly strong distinction: "why are they secure". OTP
is secure from an information theoretical model; the encrypted message
literally gives the attacker no information about the message (other than
traffic analysis things like the existance of the message). In contrast,
the stream cipher is secure from a computational theoretical basis; the
attacker has enough information to break it, but we believe that it is too
computationally expensive for him to do so. Note that, in this case, we
have no proof for that belief; the only evidence is "we thought about it
real hard, and no one has come up with a way".

> In practice, they both accomplish the same thing:
> producing a key as long as the message itself. The period of the MT is
> 2^19937 - 1, long enough for any practical message.

That's another typical newbie error: "long period implies security". Well,
it's not true. It is true that "short period implies nonsecurity", but the
converse doesn't apply.

bystander

unread,
Jul 3, 2011, 11:25:40 AM7/3/11
to
On Jul 2, 8:30 pm, "Scott Fluhrer" <sfluh...@ix.netcom.com> wrote:
> "bystander" <ethicalb...@hotmail.com> wrote in message

OK, I'm convinced. Thanks.

Jacob

unruh

unread,
Jul 3, 2011, 6:59:33 PM7/3/11
to
On 2011-07-02, bystander <ethic...@hotmail.com> wrote:
> On Jun 29, 3:10 pm, kg <kristiag+n...@math.ntnu.no> wrote:
>> bystander <ethicalb...@hotmail.com> wrote:
>> >This is probably a very naive idea, but if a one-time-pad was
>> >implemented in code using a high-quality PRNG such as the Mersenne
>> >Twister, would it be cryptographically strong?
>>
>> Such a stream cipher (not one-time-pad) is secure if the pseudo-random
>> generator is secure. The Mersenne Twister is not secure.
>>
>> --
>> kg
>
> I agree that no PRNG is "secure" in the sense that it is theoretically
> unbreakable but I believe that sequences generated by the MT have been
> shown to have all the statistical properties of "true" randomness. For

No it does NOT have ALL the statistical properties of "true" randomness.
The size of the computer program required to generate the sequence is
far far shorter than the sequence itself (it is the MT program).

> example, sufficiently large samples pass all the Diehard tests for
> randomness. Obviously, the OTP is only as strong as the method used

Those are hardly ALL the statistical properties.

> for generating the pad. In David Kahn's book he states that the
> Soviets generated their OTPs by having clerks type "randomly" on
> typewriter keyboards! Surely, the MT is as secure as that. Soviet OTP
> encryption was broken but only because some pads were used more than
> once.
>
> It seems to me that the distinction between a stream cipher and a OTP
> is tenuous at best. In practice, they both accomplish the same thing:
> producing a key as long as the message itself. The period of the MT is
> 2^19937 - 1, long enough for any practical message.

Yes, and if someone knows how you generated the string, and your key,
they can geenrate the whole of your stream. That is just a few bytes of
info to generate millions of bytes of output.
(or 2^19937-1 bytes of output)

Spinner

unread,
Jul 4, 2011, 6:02:07 AM7/4/11
to
bystander <ethic...@hotmail.com> wrote:

>On Jun 29, 3:10 pm, kg <kristiag+n...@math.ntnu.no> wrote:
>> bystander <ethicalb...@hotmail.com> wrote:
>> >This is probably a very naive idea, but if a one-time-pad was
>> >implemented in code using a high-quality PRNG such as the Mersenne
>> >Twister, would it be cryptographically strong?
>>
>> Such a stream cipher (not one-time-pad) is secure if the pseudo-random
>> generator is secure. The Mersenne Twister is not secure.
>>
>> --
>> kg
>
>I agree that no PRNG is "secure" in the sense that it is theoretically
>unbreakable but I believe that sequences generated by the MT have been
>shown to have all the statistical properties of "true" randomness.

the irrational number pi passes statistical tests for randomness ..
except of course for the fact it's pi and easily computed to any
required length.

And of course the other minor difference between PRNG and OTP is that
the actual 'seed' key of an OTP is precisely equal to the message key
length. PRNGs compute a message key FROM a seed key of much shorter
length. Size counts, even digitally.
--
2+2!=5 even for extremely large values of 2

Jacob

unread,
Jul 4, 2011, 11:54:23 AM7/4/11
to
On Jul 4, 6:02 am, Spinner <nos...@nospam.net> wrote:

Consider this: you are given two (or several) lists of numbers and
told that the numbers in one/some were generated by a truly random
process such as radioactive decay, lava lamps, whatever, and the
numbers in the other(s) were the output of a high quality PRNG such as
the MT (or some other, perhaps better) and you had access to NO OTHER
INFORMATION, how would you go about determining which were suitable as
cryptographic OTPs?

Jacob

kg

unread,
Jul 4, 2011, 12:32:12 PM7/4/11
to
Jacob <ethic...@hotmail.com> wrote:
>Consider this: you are given two (or several) lists of numbers and
>told that the numbers in one/some were generated by a truly random
>process such as radioactive decay, lava lamps, whatever, and the
>numbers in the other(s) were the output of a high quality PRNG such as
>the MT (or some other, perhaps better) and you had access to NO OTHER
>INFORMATION, how would you go about determining which were suitable as
>cryptographic OTPs?

This is very close to the standard security notion for a PRNG.

You are either given a random string, or you are given the ouput of the
(known!) PRNG seeded with a short random string.

If you can decide which is which efficiently, the PRNG isn't any good.

(As for recognizing the output of the Mersenne twister, that has already
been discussed.)

--
kg

unruh

unread,
Jul 4, 2011, 4:34:12 PM7/4/11
to
On 2011-07-04, Jacob <ethic...@hotmail.com> wrote:

> On Jul 4, 6:02?am, Spinner <nos...@nospam.net> wrote:
>> bystander <ethicalb...@hotmail.com> wrote:
>> >On Jun 29, 3:10 pm, kg <kristiag+n...@math.ntnu.no> wrote:
>> >> bystander ?<ethicalb...@hotmail.com> wrote:
>> >> >This is probably a very naive idea, but if a one-time-pad was
>> >> >implemented in code using a high-quality PRNG such as the Mersenne
>> >> >Twister, would it be cryptographically strong?
>>
>> >> Such a stream cipher (not one-time-pad) is secure if the pseudo-random
>> >> generator is secure. The Mersenne Twister is not secure.
>>
>> >> --
>> >> kg
>>
>> >I agree that no PRNG is "secure" in the sense that it is theoretically
>> >unbreakable but I believe that sequences generated by the MT have been
>> >shown to have all the statistical properties of "true" randomness.
>>
>> the irrational number pi passes statistical tests for randomness ..
>> except of course for the fact it's pi and easily computed to any
>> required length.
>>
>> And of course the other minor difference between PRNG and OTP is that
>> the actual 'seed' key of an OTP is precisely equal to the message key
>> length. ?PRNGs compute a message key FROM a seed key of much shorter
>> length. ?Size counts, even digitally.

>> --
>> 2+2!=5 even for extremely large values of 2
>
> Consider this: you are given two (or several) lists of numbers and
> told that the numbers in one/some were generated by a truly random
> process such as radioactive decay, lava lamps, whatever, and the
> numbers in the other(s) were the output of a high quality PRNG such as
> the MT (or some other, perhaps better) and you had access to NO OTHER
> INFORMATION, how would you go about determining which were suitable as
> cryptographic OTPs?

If it were MT, others have pointed out that you could easily determine
the internal state and then predict all future outputs. Not good.
If it were a better PRNG, you could always try all keys and see if any
produced the stream. It might take a while. Or someone might discover an
easy way of breaking them.

>
> Jacob

Gordon Burditt

unread,
Jul 4, 2011, 10:01:10 PM7/4/11
to
> Consider this: you are given two (or several) lists of numbers and
> told that the numbers in one/some were generated by a truly random
> process such as radioactive decay, lava lamps, whatever, and the
> numbers in the other(s) were the output of a high quality PRNG such as
> the MT (or some other, perhaps better) and you had access to NO OTHER
> INFORMATION, how would you go about determining which were suitable as
> cryptographic OTPs?

If you can't demonstrate that the key was generated from truly
random sources, it's NOT an OTP. Without further information, none
of them are suitable.

If you can crack one of them by demonstrating it was generated from
MT, you definitely know it's not suitable. That doesn't make the
other one suitable.

If any of the following rather obvious problems are true, it's not
suitable even if the key was generated from truly random sources:
- It's already been used as a key. (This isn't a Two Many Time Pad)
- It was captured from the enemy. (Don't let the enemy generate
your keys for you).
- The truly random source belongs to the enemy. (Don't let the enemy
generate your keys for you).
- The truly random source is public information. (Clever ideas like
using a hash of today's New York Times financial section fall
apart when the enemy figures out you are doing this, say, from
a double agent, even if you can tie the stock market results
back to quantum mechanics for true randomness.)
- You have reason to believe it's been compromised to the enemy.
and you can't tell any of these things by just looking at the numbers.

Jacob

unread,
Jul 5, 2011, 9:25:59 AM7/5/11
to

I'll try one more time to make my point clear and then I'm going to
give up, I promise. :-).

You are not actually going to use either list for cryptographic
purposes, it's just an exercise, so practical issues are irrelevant.
You know with certainty that for the purposes of the exercise one of
the lists has been generated by a truly random process and the other
by a very high quality PRNG that is devoid of the usual and obvious
shortcomings. (You don't know which one.)

With statistical tests and other metrics at your disposal, but no
other information, is it possible to determine which list is which?

Jacob

Benjamin Kreuter

unread,
Jul 5, 2011, 1:29:52 PM7/5/11
to

So you give me two lists, one is definitely from a random source and the
other is definitely from a PRNG, and you ask me to label them? I could
try enumerating every possible C program (at least one of them will be
the PRNG), enumerate every possible input string (0, 1, 00, 01, 10, 11,
000, 001, ...) and run the programs in parallel with those input
strings, until I finally get an output that is a match for one of the
two lists. It will probably take a while, but you didn't say I had to
be fast, just that I had to determine which is which; eventually I will
get a match, since I am guaranteed that one of the two lists is the
output of some PRNG. There is some probability that I will get the
wrong answer (there is a chance that you happen to get the exact output
of some PRNG when you sample your random data and that I will test that
PRNG before the one you actually used), but I am going to do better than
just randomly guessing.

Usually, people speak of computational security, meaning that the
attacker must use a polynomial time algorithm, and obviously the attack
I described will not run in polynomial time. Also, the attacker is
usually assumed to have some additional information, like which PRNG is
in use and how large of a seed was used. For a one-time-pad, security
is "perfect" -- the attacker learns nothing except the length of the
message, regardless of how much time is spent on computation.

-- Ben

Greg Rose

unread,
Jul 5, 2011, 2:54:34 PM7/5/11
to
In article <7fe201ca-6cb8-41e2...@o13g2000yqj.googlegroups.com>,

This is pretty close to the current definition of
security for stream ciphers. Being able to guess
which is which with a probablility significantly
better than .5 would lead to the stream cipher
being considered "broken".

The difference is in what you wrote above: "You
don't know which [PRNG]". It is a standard
security assumption that the adversary *does* know
what PRNG(s) you might be using.

Greg.
--

unruh

unread,
Jul 5, 2011, 4:15:47 PM7/5/11
to
On 2011-07-05, Jacob <ethic...@hotmail.com> wrote:

> On Jul 4, 10:01?pm, gordonb.vx...@burditt.org (Gordon Burditt) wrote:
>> > Consider this: you are given two (or several) lists of numbers and
>> > told that the numbers in one/some were generated by a truly random
>> > process such as radioactive decay, lava lamps, whatever, and the
>> > numbers in the other(s) were the output of a high quality PRNG such as
>> > the MT (or some other, perhaps better) and you had access to NO OTHER
>> > INFORMATION, how would you go about determining which were suitable as
>> > cryptographic OTPs?
>
>
>>
>> If you can't demonstrate that the key was generated from truly
>> random sources, it's NOT an OTP. ?Without further information, none

>> of them are suitable.
>
>
>
>>
>> If you can crack one of them by demonstrating it was generated from
>> MT, you definitely know it's not suitable. ?That doesn't make the

>> other one suitable.
>>
>> If any of the following rather obvious problems are true, it's not
>> suitable even if the key was generated from truly random sources:
>> ? ? ? ? - It's already been used as a key. (This isn't a Two Many Time Pad)
>> ? ? ? ? - It was captured from the enemy. ?(Don't let the enemy generate
>> ? ? ? ? ? your keys for you).
>> ? ? ? ? - The truly random source belongs to the enemy. (Don't let the enemy
>> ? ? ? ? ? generate your keys for you).
>> ? ? ? ? - The truly random source is public information. (Clever ideas like
>> ? ? ? ? ? using a hash of today's New York Times financial section fall
>> ? ? ? ? ? apart when the enemy figures out you are doing this, say, from
>> ? ? ? ? ? a double agent, even if you can tie the stock market results
>> ? ? ? ? ? back to quantum mechanics for true randomness.)
>> ? ? ? ? - You have reason to believe it's been compromised to the enemy.

>> and you can't tell any of these things by just looking at the numbers.
>
> I'll try one more time to make my point clear and then I'm going to
> give up, I promise. :-).
>
> You are not actually going to use either list for cryptographic
> purposes, it's just an exercise, so practical issues are irrelevant.
> You know with certainty that for the purposes of the exercise one of
> the lists has been generated by a truly random process and the other
> by a very high quality PRNG that is devoid of the usual and obvious
> shortcomings. (You don't know which one.)
>
> With statistical tests and other metrics at your disposal, but no
> other information, is it possible to determine which list is which?

Probably noti, especially since one of the definitions of a "very high
quality PRNG" is precisely that you cannot distinguish it from a random
stream with standard statistical tests. But so what? That has nothing to
do with cryptography, In crytography, you must assume that your opponent
knows which PRNG you are using and exactly how it works.

>
> Jacob

Thomas Pornin

unread,
Jul 8, 2011, 5:35:25 PM7/8/11
to
According to bystander <ethic...@hotmail.com>:

> The period of the MT

The period of a PRNG is not a good measure of its security. An extremely
short period (e.g. below 2^128, if you target 128-bit security) is a
weakness, but an extremely long period says nothing about security. For
instance, if you use as "PRNG" the concatenation of the successive
values of a 256-bit counter, you get a comfortable period of 2^264, and
yet there is no security worth speaking of in such a system.

More generally, if someone wants to show the security of a PRNG by
advertising a huge period, then you know that this guy is not a
cryptographer (or was a cryptographer in the 1930s'), and it is time to
find another vendor.


--Thomas Pornin

WTShaw

unread,
Jul 12, 2011, 6:48:31 AM7/12/11
to
On Jul 8, 4:35 pm, Thomas Pornin <por...@bolet.org> wrote:
> According to bystander  <ethicalb...@hotmail.com>:

Given the variability of texts and the one-way attribute of the
counted hash technique, a generated stream of permutations can be used
as a reasonable pad. The mathematics involved would be characteristic
of the character set chosen. There are also other ways but making
something from almost nothing textwise is doable and is likely the
equivalent of converting a little mass to lots of energy in effect.
Revisit my demo if you can find it.

jbriggs444

unread,
Jul 12, 2011, 1:27:17 PM7/12/11
to
On Jul 12, 6:48 am, WTShaw <lure...@gmail.com> wrote:
> Given the variability of texts and the one-way attribute of the
> counted hash technique, a generated stream of permutations can be used
> as a reasonable pad. The mathematics involved would be characteristic
> of the character set chosen. There are also other ways but making
> something from almost nothing textwise is doable and is likely the
> equivalent of converting a little mass to lots of energy in effect.
> Revisit my demo if you can find it.- Hide quoted text -
>
> - Show quoted text -

The analogy with mass and energy is just plain stupid. And wrong.

WTShaw

unread,
Jul 17, 2011, 11:14:56 PM7/17/11
to

The strangest thing when dealing with different fields of science of
science is that same equations arise under quite different areas. I
was as surprised as possible when the code did the seemingly
impossible. With larger information units, the per element value
rapidly increases and not decreases as flat-world theorists would
imagine. Of course, some bases are more fertile grounds for such
antics then others. I am eager to experiment with logic as I can, even
press the limits of given programming languages as I have always done.
It's a colorful crypto environment out there if you can get beyond
just black and white. Refute the data if you can, still there if you
look under extrapolation.

WTShaw

unread,
Jul 20, 2011, 12:13:59 AM7/20/11
to
On Jul 12, 12:27 pm, jbriggs444 <jbriggs...@gmail.com> wrote:

Next you will tell me that words are not powerful. The fabric of real
text is what is sought in seeking to solve a cipher. The goal of the
cryptographer is to deny the attacker any advantage. An OTP based on
text gives an advantage because of the interplay of the fabric of two
streams. One way to make sure the key does not have this bias is to
make it a stream of permutations of the necessary set. An input text
stream should be preformatted to the same set requirements. I see that
base 31 is about the minimum for basic text uses but others and added
multiplexing compression can make other bases do as well if not
better. http://cryptopopcorn.com/Crypto/docs/bases.html summarizes my
considerations of various bases.

WTShaw

unread,
Jul 20, 2011, 12:26:40 AM7/20/11
to
> On Jul 12, 12:27 pm, jbriggs444 <jbriggs...@gmail.com> wrote:

> > The analogy with mass and energy is just plain stupid.  And wrong.
>

Taking jbriggs444's above comment alone, below is a list of 100
casually extrapolated base 31 permutations easily generated from it.
There are optional steps to make it even more obscure since this list
in its original generated order:

©th?,lzkpbvwcrdfsgui!mxn.yje/qao
©hnpdlrbowc!qsgxeimztaj,/ukv?.yf
©eaxvy.jbgdwpcn/z!fsmuloh?rt,ikq
©aquoi!,pftldzr/bxmkhwygs?en.vcj
©ngrkwsczelft?jmdyu.oi/va,hqbxp!
©argqtxvjyon/hplbwd!kf,ucse.?mzi
©ljrdpezc?.nmbw/i,aqkhovgyust!fx
©ofauky?,!n.ec/gwvsijpxlqtdrbmzh
©g.ftvqur!zm?dhyewcns,bokj/pxila
©yg.qzwdueo!sjtxrmkcv/lhb,p?anif
©wtquz?msxgh,bkajnrfie./ol!cdvyp
©iqrtbad!clefpg,w.mzu?xhyjvs/nok
©tdopsq,nkx!yhfbjw.rclmigze?/vau
©ha.iupsrgdzyvq?fbemctoj/,xnk!lw
©mocp.ukawbslfzqx!t?vg/ejir,dyhn
©aslohrmtc,eudy/gz.piw!fb?nkvxjq
©svtnfcyzhx/adrg!jm,.bko?epluwiq
©sioal?w.,tzmbqugeydrn!/ckhpjfxv
©afc?gtlzx,uwyn/pe!hb.vsjdqmiork
©nbwug?pz/lhqkotdjfsiyexcr!m,av.
©d,kmgcpohnr/aljyutfxew.qs!?zbiv
©elxmt,jhgsqubo/ap.icrn?d!kwyzfv
©nftz.gykwids,ch/v?oj!qlmauxrpeb
©ek/l!zhomp.fi?rsnvajtgywubxqcd,
©r,tekgonqvf?zix/cw.sjhmpu!ydlba
©gjksowluhticedn?!.bxmvazq,rfyp/
©yepzuhtvqrj!wdgck./nfilba?,msxo
©ic.wa/fpdqgjoyxmrutvek?zl!h,bsn
©sdxcivm?fkby,urte/lz!hqagjn.owp
©jasqnpvkd.rhml/u,y?bzioxgt!cfwe
©upnke,qxiy.os!mgzcbdjlvhw/rft?a
©sgvhkfm?jcywldioz,/tnrquap!b.ex
©tmjqrwdgva/ki,ucln.exh!ybz?opfs
©p/tnradhs,ojiwufvzelcqyb?!m.xkg
©losnqz!aghpxbirfvdu,mtjkc/ew?.y
©axjemufi.?rkwpb!hn,sogdqvl/czty
©im?ko!n.f,lgsztxavrwhy/pebuqcjd
©nixej!c?lhdbqakz.ptmr,fgswy/ouv
©sh/cfva!ndbmjexrk,luwztyoqg?p.i
©tzbwco.,dvn/afgympqxuiles?jhk!r
©uxirh!oema/d,jzgylfnwptqbs?vck.
©p?uvdxt/br.m,jn!eisayozwcqhflgk
©i!ajeznd,hygt/mcl?uq.pbksvfwrox
©d!uizsvqb/,najlh?eycpx.mkwtfrgo
©.!hjnbt,?cryifgw/qzvkumposadexl
©awtzuonk.reb?xpqjcg,ivdfylh/!ms
©ndzhrl?fajc.!iwoemvtbk,xup/sgqy
©dwjkgaeizfprtqhnycmv.uxlo,/?b!s
©w.?xsaeciqtou,rmfzvhb/!dypkglnj
©rbvp.c,mxosy!qhgjnt?waukfze/ild
©oxkuidb,sc/twgprfqyhe!vam?jl.zn
©nsxyphwtgjlv!mcuof.?qerz/bid,ka
©gtbkcqw!jayise.v?/oldufzhpnrx,m
©.ptfug!sn?ojr/zhldv,ebyqimcwaxk
©t,/hfiox?gkmj!q.nyudlverwabzpcs
©hyl!xj/q.trzia?bpwenkmcso,dvfug
©ebx.gjpuqrvhno,y/damtcwlzfs?!ki
©ajsbc!prythwokd?mv/ue,q.nfilzgx
©nlpwajghxyvdb,?z.ktr/!fqmicouse
©aw,lfer.gscjybkhd/pvtmxoz!niqu?
©luabh.!t,ewzqk/jcfnsdm?yivoprxg
©oaklu?tbvhn/iz,q.dsgfyrcxpjem!w
©gnxfbuwimatzsq,ovpj.c?hlyr!dek/
©ygfp/ksdj?nhmxcoru!vbitlqe.aw,z
©wdhilaon?.,tprckfg!sveu/xjmbqzy
©iobprtlcfasw!kvdmghynjux?qe.z/,
©tbxwefzoviapmhqd/?ys.lng,!cjurk
©hoizngtpljus!w?,.qaexbd/vrkfcym
©mxrofytl/b?wicdhvepsqgu!.zank,j
©aucklmpqfo,eithv/sxjw!ybd?.grzn
©sjfubh/ltcq!arxo,dynemgpkivw?z.
©sjmhpbz!,g/.lcukorndwfxa?evtiqy
©akjvzxbsclefpyunh!?doq/rm,i.wgt
©nbgyuemoprjzvhil!/cq?.afdtswxk,
©dgjukczsxw/epibnvl?.ymho!qart,f
©erhqkw!,cfzvymsoalbgpu?nxd/j.it
©nylp,jbhv.kqmft/oix!wag?scdruez
©ebpkftghomcrjisnqa!y/uz,w?vl.dx
©rwesxak/fb,vpdhiocnu!?.jzglqmty
©gtxnk/jeylwchpqu.am!ir,zs?bdofv
©yucpfijnqwtz,hlsmrokevb.xg!a?/d
©iuwkty,qb.ex!v?opnafcz/sjldhmgr
©shlyfv/kutwqmjbznri.cadgx!?oe,p
©jrztng/eumovpawb,?shi!xdlcfk.qy
©uqorjdclzvsnhixwpeg.?y,kmtfa!/b
©snxlktpr.ziw,/byvqo?jhegu!cfadm
©tmsvngcbqz?uw,fpla./xkdjihry!oe
©piwx!jt?guhkfcznylsrovd/,.emaqb
©lo/fepmbi,ucszawkrj.nqx!dh?tygv
©amjlesz/rwtxd.nqhi,byf!kgucpvo?
©iamnscbkgpth!qjzvdxwe,?.rlyouf/
©njr?y.q/mvsz,lwteabpfhogukdix!c
©seb!fxvhkj?dyiu.pqlmo/zcatg,nrw
©tewxgjz.qskdop?vnhiu,a!fmlby/cr
©u/cfqe?.vpgntkbws!omdljyhrx,aiz
©pqk/v?msgj.,wyozxd!ilteuachfnrb
©ihprn!fylstm,juecaboz./qdg?wkxv
©dg.uykl!ewn?vrqbozif,smajptcxh/
©.wgnbmp?/drhsefzvouictaqlx!,kyj
©ayncjdvkstqzg,uporh?ml!i/wbx.ef

jbriggs444

unread,
Jul 21, 2011, 9:36:01 AM7/21/11
to
On Jul 20, 12:13 am, WTShaw <lure...@gmail.com> wrote:
> On Jul 12, 12:27 pm, jbriggs444 <jbriggs...@gmail.com> wrote:
>
> > On Jul 12, 6:48 am, WTShaw <lure...@gmail.com> wrote:
>
> > > Given the variability of texts and the one-way attribute of the
> > > counted hash technique, a generated stream of permutations can be used
> > > as a reasonable pad. The mathematics involved would be characteristic
> > > of the character set chosen. There are also other ways but making
> > > something from almost nothing textwise is doable and is likely the
> > > equivalent of converting a little mass to lots of energy in effect.
> > > Revisit my demo if you can find it.- Hide quoted text -
>
> > > - Show quoted text -
>
> > The analogy with mass and energy is just plain stupid.  And wrong.
>
> Next you will tell me that words are not powerful.

Would you claim that because words are powerful, we should
measure them in units of watts?

You have claimed that key expansion "likely the equivalent of
converting mass to energy".

1. The word "likely" indicates that you think there is a
physical fact of the matter here. *boggle*

2. You seem to think that e=mc^2 means that a little
mass makes a lot of energy because "c" is a big number.
That's not a physical fact -- it depends on your choice of
units. In natural units where c=1, a little mass is
equivalent with an numerically identical amount of energy.
There's no expansion at all.

3. There is no meaningful analogy here and there are
no equations in evidence.

WTShaw

unread,
Jul 22, 2011, 3:37:09 AM7/22/11
to

So it seems....there is at least some metaphor as well as some hard
substance. I don't dismiss a better way of representing the ultimates
but relationships of information units is scientific law whether you
like it or not. As ideas are often causes of the expulsion of hot air
from various sources, watts may be a useful terms. Related perhaps is
the situation here were cooling is highly desired in this Texas heat
and governor's ambiguity. In order to get cooler and less humid air,
inside I turned on a dehumidifier to decrease the humidity inside as
it immediately puts out mostly hot air itself; but the recirculation
cooling unit is therefore physically able to cool much better (me) as
the humidity level lowers. Life can be full of contradictions that
are not so in a bigger scheme.

The transistor is a simple device these days that like older vacuum
tubes allows magnification of control weather voltage and/or current.
With a few decisions amongst numerous choices, keying material can be
switched, sifted, shuffled as it expands with the added state from
such protocol decisions. As you see, it takes lots of words to
approach the relative functioning circumstance.

If you wish, I can expound on the physical laws as they apply in
analogous ways to cognition since perception, masking, camouflage of
it is what we mess with here...not foreign to the descriptive essences
of all reality at all, but I suppose I have left you already. Please
persist.

Yes, the essence of many differences, units, choice and/or absolute
values. The expansion of one quantity is relative to the specific
contents and approachabilities of all constituents, higher sets having
select concentrated values when in actual useful expressions but
compactions that can be greatly expanded to take more information
space when crumpled or puffed with esoteric ether. Vacuous space is
not empty space but filled with much content of specific other kinds.
Keys can be expanded via calculated noise generated by the tearing
against their previous order, with an addition of the unseen to become
the magically visible that was really there all the time. But, the
mechanism is not magic, I did not create it, and it was documented
before my time. As a researcher, I grasp at the obvious that was
worthy of predecessors to mention and worthy of some to later hie so
it might go away for those not privy to it by classificational
choice...such is sometimes the obstacle of investigative science.

But, the proof is in the pudding, and I am a very good cook with
selected ingredients. Let's get on with it...

WTShaw

unread,
Jul 22, 2011, 3:42:27 AM7/22/11
to

BTW, the equations that produced the listed sequence are real,
functional i javascript, and only part of what I might have used. I
use the permutations in the form of endless sequences. For example,
note the first letter of each as representing your words, not mine.

WTShaw

unread,
Jul 22, 2011, 3:45:36 AM7/22/11
to

You do want to explore the equations?

jbriggs444

unread,
Jul 22, 2011, 8:36:06 AM7/22/11
to
> selected ingredients. Let's get on with it...- Hide quoted text -

>
> - Show quoted text -

This is a prime example of kookery, not cookery.

WTShaw

unread,
Jul 23, 2011, 3:41:47 AM7/23/11
to
On Jul 22, 7:36 am, jbriggs444 <jbriggs...@gmail.com> wrote:

>
> This is a prime example of kookery, not cookery.

I detect your unscientific yearning to dismiss and ignore the data but
to solve a problem was never your goal, just to throw a ball on the
playground to kick it about and kill time. You appear to be showing
prejudice and/or ignorance...really often the same thing.

Meanwhile the two lone input requirements to make a "SetNPad',
Set31Pad, are

1) A PERMUTATION of the set including all characters to be used, and

2) SEED TEXT containing a minimum of characters greater that the size
the set, to 100 Characters (Desired) to a maximum that can be used in
the design of 100 times the number of characters in the set (3100 for
a set of 31 which will also be the maximum size of formatted text to
be encrypted without repeating a series of the 100 permutations.

Operationally, the requirement should be a

3) GENERATION PROTOCOL that will effectively render the sequence of
permutations unsolvable due to desired nonlinear handling. The
example had only a rotation of the permutations to the input text and
no shuffling of the 100 perms which would otherwise be standard.

For this design the

4) SET is 26 alphabetic characters, period, comma, question mark, "!"
for UPPER CASE letter, and "/" for a single space and "//" to separate
paragraphs.

5) FORMAT LIMITS are that no sequential spaces are allowed, non-
separated short lines, leading indents, or multiple adjacent blank
lines together.

The proof is in the pudding so the ingredients are to be well chosen.


jbriggs444

unread,
Jul 25, 2011, 7:51:11 AM7/25/11
to
On Jul 23, 3:41 am, WTShaw <lure...@gmail.com> wrote:
> On Jul 22, 7:36 am, jbriggs444 <jbriggs...@gmail.com> wrote:
>
> > This is a prime example of kookery, not cookery.
>
> I detect your unscientific yearning to dismiss and ignore the data but
> to solve a problem was never your goal, just to throw a ball on the
> playground to kick it about and kill time. You appear to be showing
> prejudice and/or ignorance...really often the same thing.

Naw. I was just peeved when my bullshit detector broke its needle
against the stop on the high end.

I paraphrase the claim to which I originally objected here:

1. It is possible to algorithmically expand an input key to produce
an
output key.

2. The expansion is by a fixed ratio of input key size to output
key size.

3. The expansion ratio is probably given by c^2 where c is the
speed of light in a vacuum.

I called bullshit on the third point. Your subsequent posts, taken at
face value [which is not really a tenable interpretation] indicate
that
you don't know enough physics to understand your own claim
but that you do have a willingness to persist in arbitrary statements
regardless of their truth, falsehood or relevance.

Please tell us the numerical value of the speed of light that
most probably produces the correct key expansion ratio

3*10^8 ?
3*10^10 ?
186,000 ?
6.02*10^23 ?
1 ?
[mumble] big number [mumble] ?

Justify with dimensional analysis.

Greg Rose

unread,
Jul 25, 2011, 1:28:48 PM7/25/11
to
In article <e908bf35-1420-4850...@g16g2000yqg.googlegroups.com>,
jbriggs444 <jbrig...@gmail.com> wrote:
>6.02*10^23 ?

That's Avocado's number: the weight of the earth
expressed in Avocados.

Greg.
--

unruh

unread,
Jul 25, 2011, 2:30:43 PM7/25/11
to

That is beautiful. Where did you get that?

Greg Rose

unread,
Jul 25, 2011, 3:08:09 PM7/25/11
to
In article <slrnj2rdij...@wormhole.physics.ubc.ca>,

I made it up, some years ago. I noticed the similarity
in orders of magnitude, and something made me think
of avocados...

Greg.
--

unruh

unread,
Jul 25, 2011, 11:43:45 PM7/25/11
to
On 2011-07-25, Greg Rose <g...@nope.ucsd.edu> wrote:
> In article <slrnj2rdij...@wormhole.physics.ubc.ca>,
> unruh <un...@wormhole.physics.ubc.ca> wrote:
>>On 2011-07-25, Greg Rose <g...@nope.ucsd.edu> wrote:
>>> In article
>><e908bf35-1420-4850...@g16g2000yqg.googlegroups.com>,
>>> jbriggs444 <jbrig...@gmail.com> wrote:
>>>>6.02*10^23 ?
>>>
>>> That's Avocado's number: the weight of the earth
>>> expressed in Avocados.
>>
>>That is beautiful. Where did you get that?
>
> I made it up, some years ago. I noticed the similarity
> in orders of magnitude, and something made me think
> of avocados...

I'm going to steal it. (Hope I remember to reference you!)
99g is a touch small for an avocado, but not by much ( and there
exist mini avocados with about that weight)
I love it.

>
> Greg.

WTShaw

unread,
Jul 27, 2011, 12:54:36 AM7/27/11
to
On Jul 25, 10:43 pm, unruh <un...@wormhole.physics.ubc.ca> wrote:
> On 2011-07-25, Greg Rose <g...@nope.ucsd.edu> wrote:
>
>
>
>
>
> > In article <slrnj2rdij.bia.un...@wormhole.physics.ubc.ca>,

> > unruh  <un...@wormhole.physics.ubc.ca> wrote:
> >>On 2011-07-25, Greg Rose <g...@nope.ucsd.edu> wrote:
> >>> In article
> >><e908bf35-1420-4850-a902-e7cb6c351...@g16g2000yqg.googlegroups.com>,

> >>> jbriggs444  <jbriggs...@gmail.com> wrote:
> >>>>6.02*10^23 ?
>
> >>> That's Avocado's number: the weight of the earth
> >>> expressed in Avocados.
>
> >>That is beautiful. Where did you get that?
>
> > I made it up, some years ago. I noticed the similarity
> > in orders of magnitude, and something made me think
> > of avocados...
>
> I'm going to steal it. (Hope I remember to reference you!)
>  99g is a touch small for an avocado, but not by much ( and there
> exist mini avocados with about that weight)
> I love it.
>
>
>
>
>
> > Greg.

Remember that if you eat too many avocados, you have a good chance of
breaking out in a rash of dark specks. About me, studied nuclear
physics, taught physics and chemistry, worked years in electroplating
and munitions industries as a chemist, also as an electronics
designer, have have licenses and certifications in several technical
fields including electronics and communications. "You have to think
high to rise."

As tired as the OTP discussions are, I think I have something in using
permutations as the key stream thereby assuring random appearing
ciphertexts.

Greg Rose

unread,
Jul 27, 2011, 1:21:29 AM7/27/11
to
In article <455bd44f-c700-4aa9...@m18g2000vbl.googlegroups.com>,

At least my ridiculous observation was amusing.

Greg.
--

David Eather

unread,
Jul 27, 2011, 7:05:50 PM7/27/11
to

You also claim to be a bioligist

WTShaw

unread,
Jul 28, 2011, 11:09:06 PM7/28/11
to
On Jul 27, 12:21 am, g...@nope.ucsd.edu (Greg Rose) wrote:
"

>
> At least my ridiculous observation was amusing.
>
> Greg.
> --

We are here but to entertain for sure.

WTShaw

unread,
Jul 28, 2011, 11:24:11 PM7/28/11
to
On Jul 26, 11:54 pm, WTShaw <lure...@gmail.com> wrote:
>
> As tired as the OTP discussions are, I think I have something in using
> permutations as the key stream thereby assuring  random appearing
> ciphertexts.

The associated methods of generating permutations for use in a pad can
utilize no-linear processes. I suppose that my experience with
offshoots of the M-94 means that permutations can be wheels, rotated
to register to whatever like:

The above sentence reduces to:

©xmfauvrcobygdphznsewtkliqj
©gcuxnlmshaevdwyjoqbkifrtzp
©iyjoakdcwrgsxmephtfnluzvqb
©nghoiajztudkpxweymcqlvrfbs
©aupojlcfvwydghmzixneqstrkb
©suiaveoykdwbxlfmtgcnzphjqr
©oaxjpdqfmrkygvcbshztlnweui

registered left to "whatever":

©wtkliqjxmfauvrcobygdphznse
©haevdwyjoqbkifrtzpgcuxnlms
©akdcwrgsxmephtfnluzvqbiyjo
©tudkpxweymcqlvrfbsnghoiajz
©eqstrkbaupojlcfvwydghmzixn
©veoykdwbxlfmtgcnzphjqrsuia
©euioaxjpdqfmrkygvcbshztlnw

sorted to alphabetic:

©akdcwrgsxmephtfnluzvqbiyjo
©eqstrkbaupojlcfvwydghmzixn
©euioaxjpdqfmrkygvcbshztlnw
©haevdwyjoqbkifrtzpgcuxnlms
©tudkpxweymcqlvrfbsnghoiajz
©veoykdwbxlfmtgcnzphjqrsuia
©wtkliqjxmfauvrcobygdphznse

then regenerated to a new collection:

©akdcwrgsxmephtfnluzvqbiyjo
©kuhnfbvarlzyqdotexcgmjswip
©qbyohrvznmeuialtgsfwckpjdx
©enkgytcxdabvmsfphwqulziojr
©fticphraemgsulzoknbdqxwjyv
©zipyqtwsvnajbkdroefxuglmch
©gfnwbeltxskuipyqmdvoczajhr

The butterfly effect could be shown:

mix©akdcwrgsxmephtfnluzvqbiyjo
©kuhnfbvarlzyqdotexcgmjswip
©qbyohrvznmeuialtgsfwckpjdx
©enkgytcxdabvmsfphwqulziojr
©fticphraemgsulzoknbdqxwjyv
©zipyqtwsvnajbkdroefxuglmch
©gfnwbeltxskuipyqmdvoczajhr

regenerated to be:

©mixakdcwrgsynephtfoluzvqbj
©jyqdtnlpxvcgsukwerombfhazi
©nyfbtarvqhxdsplzwecjkuoimg
©uljsavzbetkmfdgyncoirhwpqx
©qctlispxvuehkndabfrjogmyzw
©swhydfxabzeimotplnrukqgjvc
©mycwfsbikrpgautlqdvnexozjh

and finally registered to "j":

©jmixakdcwrgsynephtfoluzvqb
©jyqdtnlpxvcgsukwerombfhazi
©jkuoimgnyfbtarvqhxdsplzwec
©jsavzbetkmfdgyncoirhwpqxul
©jogmyzwqctlispxvuehkndabfr
©jvcswhydfxabzeimotplnrukqg
©jhmycwfsbikrpgautlqdvnexoz

There are endless possibilities from which to choose.
I can't see solving this backwards.

WTShaw

unread,
Aug 11, 2011, 1:14:50 AM8/11/11
to
I do realize that the OTP has several problems with a positive or two
but there are other fixes that can cover all the deficiencies as the
ways out are not the original ambiguous algorithm but in spite of it.
When I did solve those problems in 1994 in a particular means, it went
against the blind statements of faith then as now. So for the
unbelievers of reality as opposed to the skeptics of solutions, learn
that science takes no prisoners and seeing conformation is not a sin
but merely a part of progress. Cheers...

WTShaw

unread,
Aug 21, 2011, 12:28:53 AM8/21/11
to

Can I spell "confirmation" as needed? I find ciphers fun, even in the
wee hours or as an escape from 100+ degree afternoons.

0 new messages