58 lines
2.0 KiB
Markdown
58 lines
2.0 KiB
Markdown
# Requirements
|
|
|
|
* 2 Gbps operation
|
|
* Handles both encrypt and decrypt
|
|
|
|
At reasonable FPGA speed of 250MHz, 2 Gbps requires a minimum width of 8 bits.
|
|
|
|
32 bits is a reasonable data width that would be common to see, and lets us
|
|
have more breathing room while still maintaining line rate.
|
|
|
|
Module inputs and outputs
|
|
|
|
* clk
|
|
* rst
|
|
* data_in [31:0]
|
|
* data_valid
|
|
* data_ready
|
|
* data_last
|
|
* r [127:0]
|
|
* s [127:0]
|
|
* mac [127:0]
|
|
* mac_valid
|
|
|
|
There is no output backpressure. since the result is just a single 128 bit number,
|
|
we don't need to have a ready signal. if you want to add backpressure, add a register
|
|
slice on the output outside of this module.
|
|
|
|
the real requirement was to get something that works...
|
|
|
|
|
|
we can pipeline chacha20 as much as we want since it is trivially pipelined
|
|
|
|
since poly1305 takes in a 32 bit stream, we can redo chacha20 to work on 32 bits
|
|
at a time instead of 256 bits. We could also reuse stages, so instead of needing
|
|
all 20 stages we can just have 2 or something.
|
|
|
|
BUT since the number 1 requirement is to get it to work, lets just use what we already have.
|
|
|
|
okay they 512 bit chacha implementation is a bit crazy. the latency is too high. we need
|
|
to come up with a way to do it 32 bits at a time.
|
|
|
|
each quarter round generates 128 bits, so we could do 1 quarter round at a time and get 128
|
|
bits per clock cycle, which is plenty fast.
|
|
|
|
if we do 1 quarter round per clock cycle, There are 20 rounds, each of which is 4 quarter
|
|
rounds, so it would take 80 cycles.
|
|
|
|
Compared to the current implementation which has 20 rounds, but each round takes 7 cycles,
|
|
|
|
|
|
this has almost half the latency. We still need to store the full state between each round,
|
|
which is 512 bits.
|
|
|
|
|
|
OHHH there is a big different here with encrypt vs decrypt. basically, it is always
|
|
the encrypted packet that goes through poly1305. If the packet is being encrypted then
|
|
it needs to get xored before going into poly1305. If the packet is being decrypted, then it
|
|
needs to go through poly1305 in parallel with being xored. |