<azonenberg_work>
gruetzkopf: if you make one that looks halfway decent i'll buy one or wo
<azonenberg_work>
lol
<gruetzkopf>
i have access to the process tech (silkscreen)
<gruetzkopf>
not mine, but the owner is present here
X-Scale has quit [Ping timeout: 240 seconds]
<azonenberg_work>
yeah i know a guy with a silkscreeen shop, i also could just put it on redbubble or something
<azonenberg_work>
the challenge is designing it
<azonenberg_work>
Not making it
<pie___>
just spam replies
<pie___>
dont even wait for a request
<pie___>
faster than light internet
Flea86 has joined ##openfpga
<gruetzkopf>
optimised icmp echo responder that starts writing out bytes as soon as it knows it's a echo request
azonenberg_work has quit [Ping timeout: 250 seconds]
_whitelogger has joined ##openfpga
<gruetzkopf>
and bounces the packet off the source to do the rest of the F* icmp
<jn__>
exactly
ZipCPU|Alt has quit [Quit: Cap'n! The dilithium crystals are ...]
GenTooMan has joined ##openfpga
X-Scale has joined ##openfpga
azonenberg_work has joined ##openfpga
noobineer has quit [Read error: Connection reset by peer]
noobineer has joined ##openfpga
azonenberg_work has quit [Ping timeout: 246 seconds]
Miyu has quit [Ping timeout: 246 seconds]
unixb0y has quit [Ping timeout: 250 seconds]
unixb0y has joined ##openfpga
carl0s has joined ##openfpga
Bike has joined ##openfpga
gsi_ has joined ##openfpga
gsi__ has quit [Ping timeout: 245 seconds]
emeb has quit [Quit: Leaving.]
GenTooMan has quit [Quit: Leaving]
noobineer has quit [Ping timeout: 250 seconds]
carl0s has quit [Quit: Page closed]
pie__ has joined ##openfpga
pie___ has quit [Ping timeout: 245 seconds]
Bike has quit [Quit: Lost terminal]
<_whitenotifier-c>
[Glasgow] whitequark commented on pull request #90: Add iCE40 boards flashing support - https://git.io/fhgKA
<azonenberg>
jn__: i actually heard about a stateless tcp server
<azonenberg>
that relied on the client to keep track of almost all the state
<azonenberg>
like, it would ack any syn
<azonenberg>
then open a socket on any syn+ack
<azonenberg>
i forget all the details, it was years ago
<azonenberg>
one of the piratebay guys was talking about it in another chan
<whitequark>
impressive
<azonenberg>
i dont know how the http / tracker side
<azonenberg>
but apparently most/all of the original tpb tracker was super duper lightweight
<sorear>
azonenberg: that's just syncookies isn't it?
<azonenberg>
sorear: no, it would open a socket on *any* syn+ack
<azonenberg>
it didnt need a syn first
<sorear>
syncookies works that way
<azonenberg>
sorear: syn cookies involve verification though, right?
<azonenberg>
there was no check
<sorear>
ok, so completely broken syn cookies
<azonenberg>
Basically yeah
<azonenberg>
i dont know how it handled tcp retransmits or anything liek that
<azonenberg>
he didnt give full details
<azonenberg>
i also cant be 100% certain the guy is who he claimed to be, but i'm about 99% sure
<azonenberg>
he had a lot of insider knowledge, was logged on from a .kh IP address when the guy in question was known to be on the run in cambodia
<azonenberg>
and i havent seen him on irc since the guy in question got arrested :p
<whitequark>
lol
<azonenberg>
he offered to skype people who were skeptical of his bona fides, to prove by video chat he was indeed gottfried svartholm
<azonenberg>
this kind of opsec is probably how they found him :p
<whitequark>
looool
<azonenberg>
i didnt take him up on the offer but the evidence does point to him being legit
<azonenberg>
that and, claiming falsely, on a public forum, to be an international fugitive seems like a great way to get the wrong kind of attention
<azonenberg>
(is self-swatting a thing?)
<whitequark>
good old self-incrimination
<azonenberg>
you'd have to be pretty dumb to get on irc and claim (with plausible evidence to back it up) that you were, say, osama bin laden a few years ago
<azonenberg>
Almost as dumb as osama actually being on irc :p
<whitequark>
i remember that osama bin laden had a counterstrike account
<whitequark>
which is ironic on multiple levels
<azonenberg>
lol
<sorear>
besides everyone's on discord now
<florolf>
azonenberg: i thought https://github.com/cynthia/hypercube was the original thing and it doesn't seem to have anything like that. might be an older version though
<azonenberg>
florolf: idk
<whitequark>
>He also played Counter-Strike, a multiplayer game in which a team of militants take hostages while counterterrorism authorities try to stop the attack. The documents don't say which team bin Laden preferred to play.
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
_whitelogger has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Asu has joined ##openfpga
futarisIRCcloud has joined ##openfpga
jevinskie has joined ##openfpga
gsi_ has quit [Ping timeout: 245 seconds]
gsi_ has joined ##openfpga
<felix_>
azonenberg: do you know a gigabit ethernet switch chip with at least one copper interface, 1 rgmii interface and 1 rgmii/rmii interface with good availability and enough documentation to get it working as a dumb switch?
m4ssi has joined ##openfpga
<azonenberg>
felix_: as of last time i checked, which was admittedly ~2 years ago
<azonenberg>
there were zero switch chipsets, with any gigabit interfaces
<azonenberg>
that were both stocked by distributors and had a non-NDA datasheet available
<azonenberg>
that may have changed since then but now i'm all in on FPGAs with a DIY switch fabric
<azonenberg>
and availability of a chipset isnt going to change that now
<felix_>
that doesn't sound very promising :/
<azonenberg>
felix_: well, when i make more progress on LATENTPACKET
<azonenberg>
i will have a f/oss switch IP you can throw down on an FPGA and parameterize how many GMII or XGMII interfaces you want
<azonenberg>
You can then add a GMII to [R|S]GMII converter in fpga fabric if you need that for the phy in question
<azonenberg>
you'd need an external phy for any copper interfaces
<catplant>
felix_: KSZ9563RNXC ?
<azonenberg>
oh interesting, micrel made a 3 port gig switch asic
<azonenberg>
looks like they do have a full datasheet, nice
<gruetzkopf>
219p
<catplant>
we linked the full datasheet
<catplant>
you rejected it because it was 3 port
<azonenberg>
yeah that makes more sense
<azonenberg>
you cant make a useful 24p switch out of these
<azonenberg>
:p
<catplant>
no
<gruetzkopf>
oh, yeah. sorry
<catplant>
but three port switches are useful
<gruetzkopf>
i may have a use for that exact part though
<catplant>
and perhaps would work for felix_' purposes
<azonenberg>
yeah i might have considered it for integralstick
<gruetzkopf>
1588-2 support is useful to me.
<azonenberg>
rmii to the stm32 and rgmii to the fpga then a phy port to the outside world
<azonenberg>
instead, i ran rmii from fpga to stm32 and rgmii to a ksz9031
<azonenberg>
So i need to put the exact same 3 port switch in the fpga now
<azonenberg>
although, it loks like the 9563 is a bad choice for integralstick
<azonenberg>
because it only has one mac port and two phys
<azonenberg>
you cant sidestep the integrated phys
<azonenberg>
(good thing, i already made the board...)
<catplant>
h damn
<gruetzkopf>
i may end up using it
<azonenberg>
catplant: so you'd need a second phy to use it
<azonenberg>
and waste the pwoer of two phys looping back over a few mm
<azonenberg>
and pcb area
<felix_>
catplant: thx! that chip looks useful
<azonenberg>
yeah i'll keep it in the back of my head if i ever need two baseT interfaces
<azonenberg>
i'm more likely to need mcu and fpga on one board with one external interface :p
<felix_>
depending on what arm soc i'll end up using having 2 copper interfaces might not be problem
<azonenberg>
baseT loopback on the board is totally workable with either an integrated phy or a separate one, it's just power hungry
<azonenberg>
that's an extra probably half watt for each side of the pipe
<azonenberg>
(worst case for gig at full power)
<felix_>
the link between the arm and the switch will probably only be 100mbit/s anyway
<azonenberg>
you're looking at more like 75 mW for each side of the link then
<azonenberg>
(going from my rough recollection of ksz9031 power consumption)
<azonenberg>
and assuming they used the same phy ip in that chip
<felix_>
basically option 0 is having only ethernet connected to the arm that does the fpga configuration and sideband stuff or option 1 to also have ethernet on the fpga, so it doen't need a pcie host to operate
<azonenberg>
yeah i cant recommend anything without seeing the board
<azonenberg>
my systems tend to be a totally different topology
<azonenberg>
i have the fpga be the brain of the system, i use ethernet as my primary interconnect
<azonenberg>
and if there is a cpu core, its job is to effectively be a "state machine accelerator"
<azonenberg>
that runs CLIs or big complicated state machines i dont want to do in rtl
<felix_>
in the system i'm planning the arm is the master; one of my reasons is that the arm soc can boot from a micro sd card and then configure the fpga, so in the worst case in the field only a new image needs to be written to an micro sd card and the system is working again
<felix_>
and i need to be able to easily load different bitstreams
<azonenberg>
yeah thats kinda the exact opposite of the topology i had planned for latentred
<azonenberg>
i was going to start an update by tftp'ing an update blob onto the system
<azonenberg>
or maybe sftp
<azonenberg>
if i get that implemented
<azonenberg>
Then the update blob would be pushed to the FPGA
<azonenberg>
FPGA would verify the signature and write to a temporary area of flash
<azonenberg>
if it checked out, copy over the fpga bitstream to its own flash
<felix_>
i'm still undecided if i'll go the ecp5-5g route or the artix7 route on the fpga side; i'll need some ddr3 memory and at least 3 5gbit/s gtp lanes
<azonenberg>
then put the mcu into bootloader mode and forcibly reflash it from the outside :p
<felix_>
sounds a bit complicated to me, but we definitely do have different approaches there ;)
<azonenberg>
(meanwhile the mcu will have no access to fpga flash at all, other than the ability to push a signed firmware blob to it)
<azonenberg>
i trust a state machine in the fpga to not get owned more than i trust the mcu to not have a bug somewhere that gives memory access
<azonenberg>
so i want the root of trust in the fpga
<felix_>
ah, ok. that's not a to big concern in my project
<azonenberg>
Yeah i may or may not do full secure boot, but i at least want secure updates
<azonenberg>
goal is to have all the firmware open source, official images signed by my internal root ca
<azonenberg>
an end user with jtag access will be free to load their own firmware with a different signing key
<azonenberg>
But over the air, it will only accept signed images
<azonenberg>
This seems like a good compromise between hackability and security for a piece of hardware like a lan switch that the average bad guy wont be able to get his hands on
<azonenberg>
if somebody is in my server rack jtagging my switch i have much bigger problems
<azonenberg>
like, the fact that the guy is in my house :p
<felix_>
yep ;)
<azonenberg>
That's probably the direction i will take with most of my platforms in th efuture
<azonenberg>
have code signing on by default but a physical button/jumper/whatever to load a new root
<azonenberg>
that requires some action you can't do OTA
<felix_>
.oO(remote physical presence via ipmi) /o\
<felix_>
i don't remember where i've seen that, but i'm pretty sure that i saw something like that somewhere...
<azonenberg>
lol
<azonenberg>
the chromebook has a screw you have to take out to root it
<azonenberg>
i like that model
<azonenberg>
doesnt matter what it is, but a physical protection mechanism of some sort
<felix_>
yep
<azonenberg>
all too often i see either no security or awful drm
<felix_>
in the new chromebooks there's the cr50 chip where you don't have to disassemble the device, but have to complete some 30(?) minutes long unlock dance and then you can get access to the debug interfaces which is pretty nice imho
<azonenberg>
yeah but its still the same thing in the end, something requiring physical presence
<felix_>
yep. but you can not only flash new firmware, but also debug the system without needing some special debugging cable and board that was rather difficult to obtain
<azonenberg>
yeah
<azonenberg>
i dont know a ton about chromebooks exactly, i just picked one up for my wife to use for light web browsing b/c her 10+ year old laptop is dying
<azonenberg>
and we don't yet have enough of an office set up in the new house to put a desktop in
* felix_
mostly knows the chrome-devices from the coreboot side ;)
<TD-Linux>
you're going to parse x.509 on a fpga?
<azonenberg>
TD-Linux: hell no, i was going to use raw ed25519 keys
<TD-Linux>
ok :)
<azonenberg>
its a single certificate that signs the firmware
<azonenberg>
no chain or anything else
mIKEjONES has quit [Ping timeout: 264 seconds]
mIKEjONES has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
flaviusb has quit [Remote host closed the connection]
tmeissner has joined ##openfpga
Miyu has joined ##openfpga
rohitksingh has joined ##openfpga
X-Scale has quit [Read error: Connection reset by peer]
X-Scale has joined ##openfpga
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined ##openfpga
Asu has quit [Quit: Konversation terminated!]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined ##openfpga
emeb has joined ##openfpga
tmeissner has quit [Quit: Leaving]
<mwk>
um
<mwk>
what's the maintenance status of ABC?
<mwk>
I see quite a few trivial pull requests sitting untouched, worrying...
<daveshah>
Alan works on it regularly, don't know how much attention is paid to PRs
Asu has joined ##openfpga
ObtuseNinja has quit [Ping timeout: 268 seconds]
* kc8apf
mostly knows chromebooks from the cr50 side ;)
genii has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
jevinskie has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
<azonenberg_work>
whitequark: my concern is how much of a benefit you'd see given the limited bandwidth and high delay of current gen fpga interconnects
<whitequark>
azonenberg_work: yeah i think this is just another useless academic fpga arch
<azonenberg_work>
they were talking about a 6-aic having 64 inputs and i'm like,. how do you plan to get 64 inputs to a logic block? :p
<sxpert>
whitequark: seems rather inconclusive
<azonenberg_work>
if anything, i think the trend we are going to see is coarser grained fpgas with more hard IP and complex blocks to reduce interconnect penalty
<azonenberg_work>
xilinx already is putting hard axi in zynq and, i think, the everest parts
<azonenberg_work>
what i want to see is hard cortex-m, microblaze, etc cores scattered through the fabric
<azonenberg_work>
just like brams
<azonenberg_work>
a cortex-m0 is about the size of a bram
<azonenberg_work>
altera has hard floats in some of their higher end parts too
Sellerie has quit [Ping timeout: 246 seconds]
* sxpert
is looking into riscV + chacha20 / poly1305 / ed25519
* azonenberg_work
prefers aes-gcm to chacha/poly because it's more widely reviewed and used
<azonenberg_work>
but 25519 seems an attractive alternative to the nist curves as far as being less footgun-friendly
<sxpert>
the nist curves that NSA f***ed with ?
<azonenberg_work>
sxpert: lol we dont actually know that
<azonenberg_work>
my personal hypothesis is that they were "footgun backdoored" in that they are intentionally secure when implemented well, and insecure when implemented sloppily
<sxpert>
better safe than sorry
<azonenberg_work>
the idea being that us gov vetted implementations are known to be free of said bugs, and are safe
<azonenberg_work>
but can interoperate with third party implementations for the purpose of maintaining standardization
<sxpert>
including dual ec drbg ;)
<azonenberg_work>
well that was a more obvious backdoor
<azonenberg_work>
the nist curves i think were intended to be easy to implement insecurely
<azonenberg_work>
but not necessarily breakable per se
<azonenberg_work>
But 25519 i trust mode just in temrs of a random implementation being bug free
<azonenberg_work>
more*
<sxpert>
yeah, it seems rather simpler
<azonenberg_work>
i want to make an rtl implementation of it
<azonenberg_work>
last time i looked nobody had an open source fpga 25519 ip
<azonenberg_work>
If we can make a good one, maybe we can get it reviewed
<azonenberg_work>
try and either get a volunteer or crowdfunded cryptanalytic pentest of it
<azonenberg_work>
i'd consider myself qualified to implement it, and be free of timing side channels (power isnt a concern for me as i dont build smartcards etc)
<azonenberg_work>
But there's always the chance of missing something re input validation etc
<whitequark>
i wonder if you could like
<whitequark>
prove it equivalent to some existing algorithm
<sxpert>
there's going to be some special things to do in the FPGA to ensure constant time
Sellerie has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 245 seconds]
m4ssi has joined ##openfpga
<azonenberg_work>
sxpert: not really
<azonenberg_work>
constant time comes naturally
<azonenberg_work>
you have to work hard to get variable time :p
<azonenberg_work>
there's no caches or anything unless you build them
<azonenberg_work>
i think rtl is easier to do safe crypto in than a normal programming language
<sxpert>
azonenberg_work: ah... right, if the thing is mostly combinatorial logic, I guess
<sxpert>
something like chacha20 is pretty easy
<sxpert>
dunno for elliptic curves though
<sxpert>
this may be more complex
<sorear>
nist-style elliptic curve arithmetic has a lot of infrequent special cases
<sorear>
if you don't handle them or if you have bugs in them, an attacker can use that
<sorear>
if you *do* handle them in software with a branch instruction … your instruction fetches are correlated with key bits, and other processes on the same host can exfiltrate data
<whitequark>
nist-style curves suck because of that
<whitequark>
also
<sorear>
(or over a network with sub-microsecond jitter; I'm not sure if netspectre / lucky13 style attacks are usable "in the field" yet but the state of the art is only going to improve)
<whitequark>
it doesnt matter if you have a dedicated core for those nist curves
<sorear>
but if you're doing RTL you don't have the incentive to variable time, a mux is just as efficient
<whitequark>
running off instruction rom
<azonenberg_work>
whitequark: yeah that was my point
<azonenberg_work>
i dont think the nist curves are backdoored per se, in that a fully correct implementation can be broken by some secret method
<azonenberg_work>
NIST wouldn't mandate the us gov use a known insecure algorithm
<azonenberg_work>
i think it's more likely they made them full of footguns then did extensive review on their own implementations :p
<whitequark>
did they mandate usg use dual_ec?
<sorear>
dual_ec isn't a known insecure algorithm from nist's perspective, Juniper issue notwithstanding
<sorear>
and I don't think it was ever mandatory, although they did bribe RSA to make it the default in their library
<sorear>
I've heard people say the same thing about AES, that the NSA influenced the process to get something with timing vulnerabilities (due to S-boxes) selected
<azonenberg_work>
sorear: see, if you use single cycle sram for the sboxes there isnt a timing vuln :p
<sorear>
although I'm skeptical - I found a contemptorary usenet thread where people were enthusiastic about Rijndael and speculating that "Rijndael is clearly best but the NSA will never allow something that secure to be selected"
<azonenberg_work>
sorear: yeah i think they actually tried to harden it
<azonenberg_work>
look what they did with des
<azonenberg_work>
lucifer got better
<azonenberg_work>
a lot of people forget nsa has two jobs
<azonenberg_work>
intelligence collection AND hardening US gov systems
<azonenberg_work>
that defensive mission is forgotten a lot
<azonenberg_work>
because it doesnt make for sexy leaks to the news
<emily>
dual_ec was meant to be only reasonably breakable for the NSA, or whatever, right
<emily>
so they don't mind the US govt using it
<azonenberg_work>
Yeah
<azonenberg_work>
it was a public key vuln
<azonenberg_work>
as long as nsa's key stays safe and you're not afraid of nsa, it's fine
<azonenberg_work>
But i dont think (say) P-256 has such a vuln in it
<emily>
I imagine the NSA would consider getting to snoop on other govt communications a win :)
m4ssi has quit [Remote host closed the connection]
GenTooMan has joined ##openfpga
mumptai has quit [Remote host closed the connection]