Conversation

Notices

1. Adrian Cochrane (alcinnz@floss.social)'s status on Wednesday, 21-Dec-2022 05:28:53 JST Adrian Cochrane

   Second thread today on hypothetically-architecting an auditory browser from hardware up! This thread: Abstracting I/O, mostly for networking. Namely: Time, randomness, error detection, & a mention of crypto.

   Time I/O starts with a resistive-capacitor (typically quartz crystals) paired with a latch constantly charging & discharging so the digital circuit has a periodic signal through which to observe time passing. This is also used to step through the machinecode being interpreted.

   1/4?

   • Adrian Cochrane (alcinnz@floss.social)'s status on Wednesday, 21-Dec-2022 05:43:34 JST Adrian Cochrane

     in reply to

     A slow*er* clock would periodically trigger some code to run (an "interrupt") which increments a 64bit counter. As mentioned in bootstrapping thread this should run even when the device is otherwise off.

     This counter would be compared against a (16bit?) register holding the next timeout, & if >= enqueues a timeout event. To be parsed via a dispatch-table generated from its corresponding output opcodes, which would update itself each time it has been partially run.

     2/4?

   • Adrian Cochrane (alcinnz@floss.social)'s status on Wednesday, 21-Dec-2022 05:53:37 JST Adrian Cochrane

     in reply to

     New timeout events would be insertion-sorted into this output opcode before regenerating the corresponding dispatch-table.

     ---

     To generate randomness suitable for cryptographic security I need to source some of that from the outside. This could be dedicated circuits (voltage decay?) or "discretization noise" inherent in digitizing an analog signal. Like the microphone I said this device has (could split audio into silence-separated "utterances" simultaneously).

     3/5?

   • Adrian Cochrane (alcinnz@floss.social)'s status on Wednesday, 21-Dec-2022 06:01:55 JST Adrian Cochrane

     in reply to

     Once I've got this "entropy" occasionally entering the OS, I need to "hash" it an "entropy pool". Salsa20 is a common hashfunction today consisting of add-shift-xor operations that can be performed on the simplest ALUs, and lempel-ziv compresses well like most crypto algorithms.

     This entropy pool would be consulted, with additional hashing, whenever a random number is needed for cryptography. This hashing reduces the input predictability as much as computationally possible.

     4/5!

   • Adrian Cochrane (alcinnz@floss.social)'s status on Wednesday, 21-Dec-2022 06:21:55 JST Adrian Cochrane

     in reply to

     Cryptography would run on the ALU (could ask questions here about securing these cryptographic certificates, at the very least I'd have external access control...) using formulas I honestly don't comprehend.

     Error-detection in the TCP/IP stack mostly consists of one's-complement sums. Trivial to implement! Leaving just the question of how the machinecode should allowing carrying bits between the same or different registers.

     5/5 Fin for today!

   • Adrian Cochrane (alcinnz@floss.social)'s status on Wednesday, 21-Dec-2022 06:27:51 JST Adrian Cochrane

     in reply to

     • Charles U. Farley

     @freakazoid Yes, definitely! Don't compress the cyphertext. I'm talking about the implementation, imagining I save some registers from loops via preprocessing.

   • Charles U. Farley (freakazoid@retro.social)'s status on Wednesday, 21-Dec-2022 06:27:52 JST Charles U. Farley

     in reply to

     @alcinnz "and lempel-ziv compresses well like most crypto algorithms."

     Uhh, what? I'm guessing you're not referring to the ciphertext, since compressible ciphertext would indicate a broken crypto algorithm.