FPGA

[Jared]

Monty J. Harder wrote:
> On 8/11/07, *Jared* <jared at hatwhite.com <mailto:jared at hatwhite.com>> wrote:
> 
>     breasts. Better to stay with the industry-standard term for the
>     smallest particle of ternary calculation: "trit." 
> 
> I didn't know there was an industry.  I thought the whole point of the 
> discussion was that the industry was strictly binary.

Yes: the term "trit" goes back to the 1960s at least. There actually
were some ternary computers built in Russia in the 1960s, and
some experiments were done here as well. Only in the past few
years has there been a resurgence of interest in this interesting
"industry." So, yes, there is an industry, and one of its
internal debates is whether to use the word "trinary" or "ternary,"
with the latter being more technically accurate, but the former
being more popular.

The whole matter is easily confused with other, specialized uses
of the term "ternary," with the famous example being the most elegant
way to store data for quick retrieval: use a ternary search tree.
Any C programmer probably learned about this in his intro classes.
Fortunately, this example is not too distant from what we're talking
about here, so it all works out in the end. The point is, ternary
structures ARE REALLY INTERESTING.

>     The software running inside that "impossible" black box is ternary,
>     and uses pattern-based analysis to decrypt. Instead of decrypting a
>     small string by using hundreds of thousands of password strings,
>     each varying by a single character until you stumble upon the
>     correct one, you decrypt by studying the layers of _patterns_
>     generated by any encryption process. Once you open the first
>     layer, the others become successively easier, because each layer
>     gives clues to the next.
> 
> Anyone using a password like this isn't really protecting their data 
> from an attacker with crypto knowledge (or access to common cracking 
> tools).

True. You do have a point here. Let me more precise then, what we're
discussing is the case where data is available, but in encrypted form
without a key. In such cases, a key will soon be unnecessary....

>     The only way to prevent such pattern-based analysis from cracking
>     open any binarily-encrypted clump of data, or even a packet stream,
>     is to generate TRULY RANDOM keys, which can only be created ... you
>     guessed it ... within a ternary pattern-based algorithm. You already
>     know that binary algorithms can NEVER create true randomnness, but
>     can only emulate it with ever-increasingly fine precision. Like
>     approaching infinity; you are always approaching it, but never quite
>     get there.
> 
> I must call bullshit on this.  Ternary computation does not possess any 
> magical properties.  A number is a number, and the same algorithm 
> written in base 2, 3, 8, or 10 can also be done in 16, 256, etc.  The 
> reason why computers normally can't do randomness is that they aren't 
> designed for it.  They take inputs and perform calculations in such a 
> way that the same inputs always generate the same outputs.  They are 
> specifically designed to do things like error correction to prevent 
> producing different outputs from the same inputs.

You are correct, but you are also thinking about ternary computation
using a binary mindset, which implies that a statement is EITHER true
OR false, with an excluded middle.

Use polyvalent logic, the third option, that a statement is
"true under certain conditions" and "false under other conditions,"
and therefore its truth value is UNKNOWN, YET KNOWABLE. Now _this_
is the way to look at what is before you. If you continue to look
at it with binary eyes, you will continue to see a pile of BS.
I'm okay with that.

As you said, the fact that "a number is a number" is true. There are
no magical properties in base-3 counting, nor 3nary logic. HOWEVER,
base-3 logic does do something with that "excluded middle" which is
really amazing, and binary folks don't normally see it:

Instead of leaping from one extreme to the other, it opens up smoothly
into an infinite recursion, like fractals do. For example, something
which is VIRTUALLY TRUE, being very close to completely true, is in
this middle area. Likewise so is something VIRTUALLY FALSE, and so
is the WHOLE RANGE BETWEEN. To binary eyes, it looks like a single
empty area, neither true nor false and therefore useless. In truth
it is actually a spectrum: a window into infinity which has much
more smooth transitions than binary.

It is _this_ incremental ability that makes ternary logic much closer
to analog -- and strangely, quaternary logic is worse, not better.

Ternary, and ternary alone, is really well suited to interfacing
with the analog world, and though you are correct: "the numbers do
not change," the way we use the numbers does change.

> If you want to add randomness to computers, you need to design circuits 
> to produce random data.
> Start with something like a Geiger counter.  Every time it records a 
> hit, take the time of the event (with a clock that can do millisecond or 
> finer resolution), subtract the previous event time, and throw away all 
> but the last few bits or trits of the delta.  Take as additional events 
> every valid SYN-ACK packet received by the TCP stack, keypresses that 
> are at least 3 seconds after the previous keypress (you don't want to 
> use the internal timings of typing, because a person might have a rhythm 
> that introduces a bias into the data), and the pixels of webcams aimed 
> at busy intersections.  The idea is to use a lot of different sources 
> for the events, so that an attacker with access to one source will be 
> unable to know what other events intervened between those of which he is 
> aware.

Yes, these examples are good. Note, however, all of these are
reliant upon an interface with the analog, or "real" world. What
I am talking about is generating such randomness entirely
within the digital world, or at least so elegantly that there
is no need for a geiger counter, keyboard, or mouse movements.

>      If you are curious, here's an encrypted hint: "Babble
>     code is for babies." 
> 
> Here's my encrypted answer: "The Falcon flies east in the evening."

Excellent. Now we're getting playful, which is the whole point
of this exercise.

I have no idea what your encrypted answer means; someday I will,
but for now I am content with it as an amusing puzzle. :-)

It will be much easier to program the FPGA if we're laughing all
the way to the bank...

-Jared


p.s. for people still reading:

I met an old programmer, this guy is in his 70s now. He described
the first program he wrote, which was a way to store and retrieve
recursive sets of data for materials used in high power KCPL
transmission wires. He had an interesting labor converting the
program to C a few years later, because C does not have the
ternary structure he originally used.

In C, he created nested IF statements to emulate the more elegant
ternary structure he had used in the 1960s. I am certain that
programmers in the early 1960s thought differently about their
task than we do -- they thought in ternary, and we think in binary,
because the ON/OFF transistor has shaped the way we think about
programming logic in general. Before the transistor was invented,
people thought more fluidly than we do.

A few languages: FORTH, Smalltalk, JavaScript, and others, have
ways to extend the language dynamically, which lend them to creating
ternary structures easily. C has no such provision, and probably
won't for a long time yet. FORTH is a fork from DSSP, which is
the software which ran on the ternary computers in Russia back
in the 60s, mentioned earlier. It is also still around, and I
think it is the language used with FPGAs, IIRC.