Revised 2025-08-24

FYBB aims at becoming an Enigma-like encryption system. Not an emulation of the historic Enigma, but fuctioning by way of churning and scrambling an ASCII text key at the level of cells, bytes, and bits. The key is then used to XOR files for both EN- and DE-cryption.

While not yet a functioning system, a number of component files are already authored.

fybb.f    -- The parent file, which invokes daughter files by include-ing them.

defs.f    -- Counted string utility words and some non-core, common-use Forth words.

cwd.f     -- Identifying which Forth is being run. Getting current directory, etc.

edit_me.f -- You must edit this, very minimally, one time only. Use Gedit, Notpad, or whatever.

arry.f    -- Creates x_buff upon which words defined in other files operate, as described below.

file.f    -- Manages opening, reading, and closeing of files.

The following files operate upon x_buff either as a unit whole or an arbitrary subset thereof. Sequential addrs are treated as a contiguous whole, as if comprising a single extremely large number. This regardless of how many bytes. 

No single routine offers much security. Performed atop of one another however, the effect vastly multiplies. Bits migrate from byte to byte. Those bytes get jumbled around. XOR-ing turns 1s into 0s and vice versa. Like so over, and over, and over again.

grey.f -- Convert between binary and Grey code, any of the seven cyclic permutations.

roll.f -- Roll the order of bytes. Roll the order of bits.

shfl.f -- Shuffle bytes like a deck of cards.

swap.f -- Swap locations between pairs of bytes.

hop.f  -- Perform discrete operations upon various bytes.

kybd.f -- Get input from keyboard.

xor.f  -- XOR bytes in a daisy chain similar to how PostScript encrypts fonts.


FILES YET TO BE WRITTEN.

gigo.f -- Insert stray garbage bytes and bits during encryption. Remove same when decrypting.


MOTIVATION & PURPOSE

I continue to nurse a grudge over something which happened long, long ago. Few will remember Zimmerman's original verison of PGP. That one I very much liked. I don't trust the new one too very much. Said original version was taken away when TRW filed a lawsuit way back when. The new PGP, once it came back, suffered from its longest and sharpest teeth having being pulled. No longer could a key be whatever size the user might choose. Length was constrained to just only certain fixed sizes. What else could that be except a concession made on behalf of Big Brother? TRW, after all, was then chiefly a military parts supplier, a maker jet engine turbine blades, among other things. They had sat on the RSA patent for ages, doing nothing with it whatever. TRW took an interest ONLY when Zimmerman made RSA available to the public at large. 

Can there be any doubt but that the NSA was the real instigator behind TRW's legal action? The government cannot hold patents. Thus TRW, a military contractor, claimed patent rights on the RSA algorithm. A patent which they never once exploited, but instead sat on for nearly two decades, vending not a single software based upon it. Then suddenly, just as Zimmerman offers the public military grade RSA software ... wham!, a lawsuit to stop him. And not only that, but suddenly also legal actions against Mr. Zimmerman from various other directions. 

And so, in a fit of pique, I set out to author my own little encryption program. Nothing so brilliant as PGP, but made up for to a degree by way of vast complexity. Coded in PostScript, I named my own meager offering ENCRYPTION.PS. Driven by the least significant bits of a long pass phrase, bytes and bits got thoroughly churned. Reversably so from the same key. I distributed it for free over Compuserve. A partial objective was to annoy the NSA, however mildly. May its existence have caused druge work for some lower tier NSA minion.

Anyhow, its PostScript workings then served as prototype for a new effort yet more complex: the original FYBB.f, which I began coding in JForth on an Amiga 2000. But soon the Amiga platform met its demise. So FYBB.f in JForth never got fully completed. A decade or so later, I made half-hearted attempts at porting FYBB.f into Perl. But in this I encountered an obstacle difficlult to surmount: data typing. 

Forth has no data types. A byte is a byte is a byte. I can read ASCII (or whatever) from any file into a buffer then pretend the entire string is one gigantic unsigned number. In Perl I failed to puzzle this out.

So here I am, starting once more from scratch. As I proceed, I make regular portability checks in several flavors of Forth. In those plus any other Forths which I'm able to install, and which also prove capable.

FORTHs SUPPORTED:

1. gForth      -- Tested on both Windows and Linux.
2. SwiftForth
3. FVX Forth
4. Win32Forth

FORTHs NOT SUPPORTED: If you have a clue how to fix any of these, please do inform.

1. Forth2020 -- Chokes when INCLUDING *.f files above just only medium size. 
2. SP-Forth  -- Not tried, but Forth2020 is a fork of this forth. So...
3. ciForth   -- Too minimal. Lacks the word [IF] and doubtless others.

My ultimate plan is to produce a pair of standalone utilities for free, unrestricted use: FYBB.f and OTP.f. Thus FYBB shall serve a dual purpose. An alternate use would be for FYBB to encrypt an arbitrary file that it may serve as a one-time pad. Or, as needs may be, an N-times-use XOR pad. 

Enter OTP.f, which would employ said pad to en-decrypt multiple files very quickly. The point would be for FYBB to generate said pad files only ever onto a volatile RAM disk. Then to delete it irrecoverably after use, recreating it again at future need.

Those two each with one further feature. Output into traditional five-character groups. This for transmission over radio by whatever mode: RTTY or even Morse code, for instance.