Julian's Long List of Ideas Thread

[zhulien]

claude and gemini flavours added
proxy added e.g. https://cyborgshell.com/proxy/?url=  (for gemini)

[zhulien]

ZOSCII is ready for commercial use!  https://cyborgunicorn.com.au/zoscii/zosciibb/

Anyone want to create a CPC Assembly Language encoder?

I will try soon if nobody better than me can...

CP/M source here in the src/c folder.  https://github.com/PrimalNinja/cyborgzoscii

and Linux/Windows zencode, zdecode, zstrength

Please report any bugs to me.

[andycadley]

So it's basically a one time pad (except you might re-use the pad, which leaves it open to histogram attacks).

And you have to use 16-bit character codes on an 8-bit machine because they will be faster than 8-bit ones?? And it doesn't really explain what the "character code" is supposed to be pointing at (bitmap data?)

[zhulien]

So it's basically a one time pad (except you might re-use the pad, which leaves it open to histogram attacks).

And you have to use 16-bit character codes on an 8-bit machine because they will be faster than 8-bit ones?? And it doesn't really explain what the "character code" is supposed to be pointing at (bitmap data?)

No, one time pads relate to encryption and there is no encryption here. Zoscii relates to ASCII as its a character encoding which is the intent. If you look at the source and the whitepaper you will see the performance gain on an 8bit system vs ASCII lookups. It is quite clear.

It increases performance of text output by not requiring offset calculations to a base ASCII table. It removes the need to waste ROM space with an ASCII lookup table. It does use 2x RAM (or ROM if messages are stored there) vs ASCII but RAM is reusable and ROM usually is not.

The side effect of this scheme is an unfalsifiable undeterministic plausible deniable security option with a practical infinite entropy (if you use a random file as the ROM file).

If you want to communicate with someone with an unknown shared ROM file you have 100% security with a good enough ROM file (check the JS encoder/verifier tool for ROM strength). No message is ever actually sent.  If you want to make your most important data inaccessible to anyone without the ROM file you can have 100% secured ability to do so with zero of your data in the address file. Don't lose your ROM though,  your data will be lost forever.

[pelrun]

Saying "one-time-pads are encryption and this isn't encryption" is playing games with semantics. I can claim my face is an airplane but that doesn't make it true. A cryptologist would laugh in your face if you tried that argument on them.

This is worse than a one-time-pad (you're reusing the pad) and inherits all the same flaws that scheme has - sure, if you don't have a copy of the pad, you can't decrypt the ciphertext, but actually *keeping the pad secure* is hard. Exponentially more so once you need to communicate it to another party. If nobody is actively attacking you, sure, nobody is going to find your pad, but nobody cares if it was in plaintext either. But if you were under surveillance by a competent intelligence agency then this is going to fail and fail fast.

[andycadley]

It increases performance of text output by not requiring offset calculations to a base ASCII table. It removes the need to waste ROM space with an ASCII lookup table. It does use 2x RAM (or ROM if messages are stored there) vs ASCII but RAM is reusable and ROM usually is not.

It's much less efficient, in Z80, than just storing your character layout as a series of page aligned tables. In which case you can convert an ASCII code to a pointer with:

LD E, (HL) ; Where D holds a constant pointer to the character table

On other systems with a character mapped display, like the C64 it's even less efficient since you have to dereference a 16-bit pointer (expensive in 6502) in order to copy a single byte into video memory rather than just copying the byte in the first place.

If you want to communicate with someone with an unknown shared ROM file you have 100% security with a good enough ROM file (check the JS encoder/verifier tool for ROM strength). No message is ever actually sent. 

This is literally the definition of a one time pad. Except you have to use a different "ROM file" for every single message, otherwise it is subject to histogram attacks (over time it becomes obvious what the characters represent because distribution of letters in a language isn't uniform)

[MaV]

This is worse than a one-time-pad (you're reusing the pad) and inherits all the same flaws that scheme has - sure, if you don't have a copy of the pad, you can't decrypt the ciphertext, but actually *keeping the pad secure* is hard. Exponentially more so once you need to communicate it to another party. If nobody is actively attacking you, sure, nobody is going to find your pad, but nobody cares if it was in plaintext either. But if you were under surveillance by a competent intelligence agency then this is going to fail and fail fast.

This is literally the definition of a one time pad. Except you have to use a different "ROM file" for every single message, otherwise it is subject to histogram attacks (over time it becomes obvious what the characters represent because distribution of letters in a language isn't uniform)

Let's look at it from a more positive angle. This method probably would have postponed the premature death of Mary, Queen of Scots in 1587 by a couple of months which is a nice gesture, methinks!

[zhulien]

One time pad = illegal to export, stores payload as encrypted file.

Just because you can substitute a banana for an apple on your breakfast cerial doesn't make an apple a banana. People are more than welcome to confuse the two.

8bit performance, obviously I am not referring to character mapped output like a c64, where does a c64 add an offset of a table to a character position? We are also not comparing with an optimal way to handcode but the typical way most people do.