<azonenberg>
Started by google image searching "round nylon nut", finding things that looked vaguely similar, searching related keywords from the pages they occurred on
<cr1901_modern>
Google is amazing. I should prob use it more often
<azonenberg>
lol
<cr1901_modern>
Except the part where they spy on me. I could do without that.
<cr1901_modern>
But Google's Too Big To Fail
<azonenberg>
Lol
<azonenberg>
Well, here's the thing
<azonenberg>
The majority of my search queries don't tell you anything you couldn't easily figure out about me already from public information
<azonenberg>
Local businesses, to check their hours - well duh, it's no secret that I live here
<azonenberg>
anyone can look up my callsign at the FCC
<azonenberg>
and see my address
<cr1901_modern>
Ahhh shit.
<cr1901_modern>
I even hide my address from my WHOIS
<cr1901_modern>
TOTALLY forgot about the call sign
<azonenberg>
well i dont think there's any requirement that you reside at that address
<azonenberg>
Only that the FCC can send you mail at it
<azonenberg>
so a PO box would be (I think) totally fine
<azonenberg>
In my case, i didnt do that
<azonenberg>
Then various silicon parts
<azonenberg>
It's no secret I do electronics projects, and most/all of my boards these days are F/OSS
<azonenberg>
so just look at the github page for the project if you want to know what parts i am using
<rqou>
i set my whois to my berkeley apartment which i definitely won't be living in forever
<azonenberg>
youtube searches for fan covers of random video game/film soundtracks? Good luck deriving any useful intel from that
<rqou>
so after i move out feel free to send in the swat teams :P
<azonenberg>
rqou: i actually paid extra for private domain reg just because i was getting so much spam
<azonenberg>
so far, i am not getting much spam related to ham stuff
<cr1901_modern>
azonenberg: I thought you didn't play video games lol
<rqou>
we get so much junk mail here anyways nobody cares
<rqou>
there's been too many people cycling through here
<azonenberg>
cr1901_modern: my tastes in music are far wider than my taste in games
<cr1901_modern>
That's... fair.
<azonenberg>
probably 80% of the soundtracks in my library are games i've never played or movies i've never watched
<azonenberg>
in fact, in some cases i've decided to see a movie after hearing the score while searching for other work from a composer i liked, lol
<rqou>
hilariously enough when i was interning at NI in austin i was living in the apartments that NI got for the interns ...
<cr1901_modern>
I mean one of my fav soundtracks is the Solstice title screen, and I've never played that game lol
<rqou>
which since there was a new round of interns every year got tons of junk mail and calls
<rqou>
and since in this era no millennials actually use landlines after only about two weeks the answering machine got to "memory full"
<rqou>
:P
<cr1901_modern>
I didn't know it was possible for the NES to do this
<rqou>
this isn't a vrc7?
<azonenberg>
wow, not bad for a NES
<cr1901_modern>
stock hardware
<rqou>
wow
<azonenberg>
but in general I prefer full orchestration
<azonenberg>
never been a chiptunes/retro guy, but you knew that :p
<azonenberg>
rqou: I have a landline
<azonenberg>
i think i mentioned, i live on an island full of hills
<rqou>
you're an exception
<azonenberg>
Closest cell towers are mainland and far side of the hill
<rqou>
:P
<cr1901_modern>
azonenberg: I know :). But this particular piece kinda transcends chiptunes for me.
<azonenberg>
cr1901_modern: yeah its not bad at all
<cr1901_modern>
(Anything Tim Follin does is gold, tbh)
<azonenberg>
rqou: Although i can reach several VHF/UHF repeaters just fine on <=5W...
<azonenberg>
rqou: Right now my LTE signal is -110 dBm
<azonenberg>
and this is a good day :p
<rqou>
like i said, you're an exception :P
<rqou>
i'm pretty sure no millennials in austin have this problem
<azonenberg>
Few if any city dwellers do
<rqou>
this just reminded me of something hilarious btw
<rqou>
every since forever ago UCB gave students of EE/CS courses email addresses of the form <class number>-<two to three letters>@imail.eecs.berkeley.edu
<rqou>
i don't know if it was for preventative maintenance or if someone was legitimately using a landline in the dorms
<azonenberg>
rqou: lol
<azonenberg>
Back at RPI, for many years (I've heard rumors they may have upgraded since I graduated)
<azonenberg>
many of the dorms had 100baseFX uplinks
<azonenberg>
one per floor or thereabouts
<azonenberg>
The way they enforced fair QoS between users was to set each user port to 10/half
<rqou>
berkeley dorms were 1000base-t to each room capped to 100mbps each way
<azonenberg>
It's the only place I've ever seen 10/half used in the 2010s
<azonenberg>
This was using WS-C2924-XL-EN switches, or similar
<azonenberg>
I have a capture of CDP packets from some of them that were misconfigured to broadcast discovery
<azonenberg>
the newer dorms were mostly gig, i dont even think they were capped
<rqou>
i don't know what equipment berkeley used, but every room got a static (dhcp-assigned) public ip
<azonenberg>
just QoS'd to let other users have a fair share of bandwidth
<azonenberg>
We did that too
<azonenberg>
But they were firewalled
<azonenberg>
So no inbound by default
<azonenberg>
You could request port 80
<rqou>
berkeley's aren't firewalled
<azonenberg>
they'd run a Nessus scan on your box
<rqou>
for footgun protection there's some kind of passive ids
<cr1901_modern>
azonenberg: You bring up an interesting point re: orchestra. One of the reasons I like FM synthesis is that in theory, you can not only simulate an orchestra well, but you can mix it with appealing otherworldly sounds. >>
<azonenberg>
then open it up, with DPI at the border to verify you weren't tunneling anything but HTTP inbound
<cr1901_modern>
In practice, any instruments you make as part of "My First FM Synth" will sound like ass, but the sentiment remains
<rqou>
wow RPI is pretty draconian
<azonenberg>
this was dorm stuff
<azonenberg>
By comparison, the CSNet systems on the other /16 (before the unification of DotCIO and CSNet and subsequent munging of subnets) were like berkely
<rqou>
even our dorm stuff had only a passive ids (iirc snort)
<azonenberg>
unfirewalled public IPs in 128.213.0.0/16
<azonenberg>
after the unification they started firewalling them, but it was a lot easier to get stuff opened
<rqou>
hmm it seems 128.0.0.0/8 is all universities :P
<azonenberg>
RPI is 128.113, 128.213, 129.161, 129.5
<rqou>
berkeley is on 128.32.0.0/16 among other blocks
<azonenberg>
all /16s
<azonenberg>
oh... I was tight enough with the head of campus infosec that I managed to get OpenVPN in to my office
<azonenberg>
officially sanctioned
<rqou>
berkeley's non-dorm connections have afaik no protection at all
<azonenberg>
i set my server there as a NAT router and advertised all campus subnets, plus journals they subscribed to
<azonenberg>
to OSPF
<azonenberg>
Then peered with my border routr at home
<rqou>
except that there's no campus-wide dhcp
<azonenberg>
So i could get to ieee xplore etc via the campus subscription
<rqou>
security through obscurity
<azonenberg>
i dont know if they ever found out what i was doing
<rqou>
afaik at berkeley if you plug into a physical wired port on campus and as long as it is live and you can figure out what ip it's supposed to have you can connect
<azonenberg>
On the other hand, the head of the IT department was also the instructor of the cisco network security class
marcus_c has quit [Ping timeout: 240 seconds]
<azonenberg>
(sec guy's boss)
<rqou>
there was no 802.1x or anything
<azonenberg>
And i had taken that class
<azonenberg>
So she probably knew, whatever i was doing, i had taken reasonable precautions :p
<azonenberg>
RPI ran .1x on the wifi but wired was wide open
<rqou>
berkeley used to run captive portals on our wifi and it sucked majorly
<azonenberg>
eeeew
<azonenberg>
captive portals need to die
<rqou>
it sucked so hard the EECS department set up their own infrastructure their own way
<azonenberg>
When unencrypted HTTP is deprecated in another 5-10 years (yeah right)
<azonenberg>
they wont even work
<rqou>
it's now WPA-EAP
<rqou>
but the wifi still sucks majorly :P
<azonenberg>
i am looking forward to the day when I can block outbound TCP 80 at my border
<rqou>
i think berkeley saw the writing on the wall so they went to WPA-EAP 2-3 years ago
* cr1901_modern
isn't. I'd like my vintage computers to be able to still access the Internet without placing an RPi between it.
<azonenberg>
cr1901_modern: meanwhile as far as i'm concerned, if your hardware is too old to support TLS
<azonenberg>
it's probably full of enough bugs that i don't want it online anyway :p
<rqou>
cr1901_modern: i assume you're not looking forward to have to tunnel ipv4 over ipv6? :P
marcus_c has joined ##openfpga
<rqou>
(iirc some parts of asia/latin america already have to do that)
<cr1901_modern>
Supposedly, the guy who writes mTCP (DOS TCP/IP stack) will add ipv6, so not really an issue
<azonenberg>
My dream is to eventually block all outbound traffic from my regular home network, then allow outbound IPv6 443 and 53 to the public internet from the DMZ
<azonenberg>
And have my internal machines run VNC/RDP clients to a VM server in the DMZ to get online
<cr1901_modern>
But a 5150 or 5170 is just not going to be able to do the TLS handshake before the remote times out
<azonenberg>
I'm a ways from that being possible
<rqou>
btw i recall minecraft having a bug regarding ipv6 that was actually closed as wontfix a couple years back
<rqou>
the launcher deliberately used the java option that disabled ipv6
<cr1901_modern>
I mean, it already takes 30-40 seconds to connect SSH on my 50 MHz 486
<cr1901_modern>
And ten minutes to generate a keypair
<rqou>
this broke connecting to minecraft servers for some users that were using some isp that did some ugly carrier-grade NAT hack where they pretended the entire ipv4 internet was ipv6
<azonenberg>
rqou: lol
<azonenberg>
fwiw, in Antikernel I do not plan to support IPv4 sockets at all
<rqou>
e.g. rewriting A responses to AAAA responses in the carrier grade NAT range
<azonenberg>
at least not in my TCP/IP stack
<azonenberg>
I consider v4 deprecated, and i am very close to removing IPv4 from all of my non-internet-facing vlans
<rqou>
it would be quite easy to accuse mojang of being <trolling>problematic</trolling> because "only developing countries are at this point of ipv4 exhaustion" :P
<azonenberg>
so all of my test equipment and lab stuff will be single stack v6, and only stuff that pings out (and legacy hardware that doesn't support v6) will use v4
<azonenberg>
rqou: lol
<azonenberg>
well now that MS owns minecraft
<azonenberg>
that is likely to change at some point
<azonenberg>
right?
<rqou>
i never looked to see if they fixed this
<rqou>
it's a hack from the "have ipv6 address but no connectivity" era
<cr1901_modern>
I'm thinking of making an ISA acceleration card so old PCs can do the TLS handshake...
<rqou>
also, using an alternate launcher allows it to work :P
<azonenberg>
rqou: ISA TLS accelerator? lool
<azonenberg>
put an FPGA on it faster than the main CPU?
<azonenberg>
cr1901_modern: *
<cr1901_modern>
azonenberg: The hard disk controller in the original IBM PC used a z80
<rqou>
there's a nintendo ds flashcart that does that :P
<rqou>
there's a flashcart that has a several hundred mhz ingenic mips soc on it
<cr1901_modern>
I'm not against using separate CPUs to accomplish tasks the main hardware can't
<azonenberg>
lool
<azonenberg>
cr1901_modern: fwiw, an fpga tls implementation is definitely on my TODO list
<rqou>
there's also an atari 2600 flashcart that afaik doesn't even have any (discrete) rom/ram/flash at all
<azonenberg>
Initially it would probably be ECDH over a single curve, plus AES-GCM, as the sole supported crypto
<rqou>
it just has the 2600 bus hooked up to an arm uC
<cr1901_modern>
azonenberg: I'm against using "a piece of hardware that completely and utterly replaces the vintage machine" to accomplish a task the vintage machine cannot do alone.
<cr1901_modern>
That's why RPi is "cheating", but say, a dedicated ISA card is not
<azonenberg>
Because that is sufficient for interoperating with openssl etc clients running the FPGA as the server (my primary use case)
<azonenberg>
But client support could certainly be added, as could more algorithms
<azonenberg>
But it has to be done *right*
<rqou>
azonenberg: not doing the "djb cipher suite" of x25519, chacha20, and poly1305?
<azonenberg>
rqou: I was going to go with suit eB
<azonenberg>
suite B*
<azonenberg>
so p-256, aes128, sha256
<azonenberg>
more widely supported and i already know aes and sha well
<cr1901_modern>
Define *right*. I'm not concerned of side channel attacks on an 8088/286. Any internet access I do from those machines is throwaway anyway
<rqou>
i don't know how much i like p-256
<cr1901_modern>
The point is to be able to access the Internet at all.
<azonenberg>
cr1901_modern: I'm trying to make something safe to use in industrial control systems etc
<rqou>
not just because of tinfoil-hattery but also because p-256 has way more footguns than x25519
<azonenberg>
rqou: secp256k1 is an option too
<rqou>
i'm not sure that's any better
<azonenberg>
But i havent decided on the exact suite yet
<azonenberg>
In general, i'd want to pick something that i understand well enough that I could reliably and safely implement it
<azonenberg>
And then get an independent third party review of the code
<rqou>
good luck with EC in general then :P
<azonenberg>
I am confident in my ability to implement AES and SHA correctly and without any timing side channels
<cr1901_modern>
azonenberg: Failing a TLS acceleration card, an ARM or RISC-V micro whose sole purpose in life is to bridge insecure to secure connection is sufficient too
<azonenberg>
(power is not a concern in my typical threat model)
<rqou>
no DPA countermeasures? don't like lawsuits? :P
<azonenberg>
rqou: More like, most of the projects I work on are for embedded server type systems
<azonenberg>
where if the bad guy can get a DPA probe on your board, you've already failed
<cr1901_modern>
"I am confident in my ability to implement AES and SHA correctly and without any timing side channels" Are these just server-side problems?
<azonenberg>
because he's in your datacenter/factory
<azonenberg>
DPA matters more for client secrets where you need to protect the data from the user of the equipment
<azonenberg>
DRM, smartcards, etc
<rqou>
ugh i hate the security-through-obscurity of smartcards
<azonenberg>
cr1901_modern: Timing matters for clients and servers, but in general is mostly a concern for public key stuff
<rqou>
you mean the naive rsa square and multiply algorithm isn't good enough? :P
<azonenberg>
lol
<rqou>
it's not like you can literally read the key bits from an oscilloscope trace of the current or anything
<azonenberg>
I mean cache timing etc lets you do nasty stuff if you can run code on the same CPU as the crypot implementation
<rqou>
:P
<azonenberg>
with symmetric key stuff
<azonenberg>
But in an FPGA most of those attacks go out the window
<azonenberg>
because you have cycle-accurate timing
<cr1901_modern>
This is why security pisses me off- no one cares about my little niche and I'm too stupid to roll my own crypto
<azonenberg>
so as long as your algorithm itself doesnt have an inherent time side channel, like sq-and-mult
<rqou>
what about EC footguns like bad RNGs?
<azonenberg>
rqou: So, thats one of the other things hodling me back
<azonenberg>
that i was about to mention
<rqou>
*cough* *cough* Sony
<rqou>
:P
<azonenberg>
I've read papers on fpga-based TRNGs
<azonenberg>
I've tried a few for testing
<azonenberg>
But i'm not confident enough to ship any of them
<azonenberg>
especially i saw concerning bias in a few that i implemented off various papers
<azonenberg>
honestly, if i was using a 7 series part
<rqou>
so the djb x25519 crypto does deterministic signatures so instead of using a rng it uses hashes
<azonenberg>
What i'd probably do is use the XADC and an external avalanche diode
<azonenberg>
You still need session keys though
<rqou>
oh right
<azonenberg>
crypto will always need good randomness
<azonenberg>
What you can do is prevent long-lived key compromise in the event of bad randomness
<azonenberg>
by things like that
<rqou>
just use a prng whose value depends only on how long the chip has been powered! :P
<azonenberg>
But you cannot prevent compromise of one session if you have a bad RNG
<cr1901_modern>
How would a side channel attack manifest itself on an ISA TLS accelerator?
<rqou>
*cough* *cough* NXP
<rqou>
mifare classic
<azonenberg>
rqou: lol
<azonenberg>
Yeeah no
<azonenberg>
I was thinking of (but would need to get this reviewed before i'd use it)
<azonenberg>
internal 256-bit state
<azonenberg>
Start at some fixed value
<azonenberg>
then loop forever
<azonenberg>
read N values from ADC (hooked to external avalanche TRNG source)
<azonenberg>
state = sha256(state + ADC inputs)
<azonenberg>
To read RNG output, you check the output FIFO
<rqou>
there's a number of f/oss projects that generate randomness from avalanche diodes
<rqou>
i don't know how much i can trust them though
<azonenberg>
If empty, push sha256(state, constant) into the output FIFO
<azonenberg>
(to prevent backtracing to find current state)
<azonenberg>
Then set a "used" bit
<azonenberg>
that prevent reading another value until the next RNG update
<azonenberg>
alternatively, rather than blocking a la /dev/random you can do a counter-mode type thing
<azonenberg>
so output = hmac(state, count)
<rqou>
trolling enterprisey solution: add a secure element of some kind and hope its rng is good :P
<azonenberg>
Yes, i considered cheating by using an atsha/ataes part
<rqou>
we can totally trust nxp/infineon, right? :P
<azonenberg>
But i would be more likely to trust something based on first principles
<cr1901_modern>
why does hmac prevent blocking? Not that I have any idea what you two are talking about
<azonenberg>
cr1901_modern: So, you can't just have the output be the RNG state
<azonenberg>
as this would allow someone to predict the output (to some extent) given part of the output
<azonenberg>
iow, you don't necessarily feed 256 bits of entropy from the TRNG each update
<azonenberg>
So you might be able to predict state[1] to some extent (say, a few tens of thousands of possibilities) given state[0]
<azonenberg>
What you do instead is hash the state with some other value
<azonenberg>
in such a way that you can't backtrack to find the state
<cr1901_modern>
what does backtrack mean in this context?
<azonenberg>
Compute state given rng_out
<azonenberg>
Problem there is, after you read (say) 256 bits of RNG output (in the case of hmac-sha256) now you've already read hash(state, blah)
<azonenberg>
so if you were to re-hash the state you'd repeat output
<azonenberg>
The two possible fixes are to do hash(state, blah2)
<azonenberg>
or block until the state changes
<azonenberg>
the latter is probably the better option to prevent entropy-exhaustion performance issues like you get with /dev/random
<cr1901_modern>
Okay, you lost me :D... let's see >>
massi has joined ##openfpga
<cr1901_modern>
First, given rng_out, I thought you couldn't compute the state used to get there
<azonenberg>
If your hash doesn't have a first preimage weakness, you can't
<cr1901_modern>
And even if you could, you couldn't figure out the previous state that you came from
<azonenberg>
No, but you could potentailyl figure out the NEXT state
<azonenberg>
that's the concern
<azonenberg>
have malicious code ask for a few hundred random values
<azonenberg>
then predict the next session key of another process
<azonenberg>
or leak random values as nonces etc then predict the next session key black-box as a network-level attacker
<cr1901_modern>
Second issue... what is "blah" in "read hash(state, blah)"
<azonenberg>
An arbitrary value
<azonenberg>
concatenated/hmac'd with the state
<azonenberg>
Doesn't matter what it is or if it's secret
<azonenberg>
It can even be an empty string
<azonenberg>
the key here is, *for the same state* you can never have the same value there
<azonenberg>
or your random output will repeat the same 256-bit sequence until the next ADC read
<azonenberg>
So basically what you're doing is using the hash with incrementing values of blah as a PRNG
<azonenberg>
re-seeding from the state and TRNG output every ADC update
<azonenberg>
and PRNG-ing in the meantime
<cr1901_modern>
I see... and this works without the attacker guessing the PRNG in the meantime?
<cr1901_modern>
in the meantime == in between TRNG output
<azonenberg>
Well, as long as the PRNG is cryptographically strong and doesn't allow predicting of past/future outputs given a current output
<azonenberg>
you're good
<azonenberg>
in fact you could theoretically seed it once with the TRNG and never touch it again
<azonenberg>
and just PRNG everything
<azonenberg>
But if you have a TRNG there's no harm in continually mixing the output into the state to add more entropy
<cr1901_modern>
Stupid q: Why isn't the TRNG used directly?
<azonenberg>
Because it may be biased
<azonenberg>
you don't always have an exactly equal fraction of 0s and 1s
<cr1901_modern>
Then why is it useful at all?
<azonenberg>
you may have bursts of noise
<azonenberg>
etc
<cr1901_modern>
Well actually...
<cr1901_modern>
Why is biasing bad?
<azonenberg>
in key material, it reduces your search space
<cr1901_modern>
You do realize that I could go on w/ questions all night, right :)?
<azonenberg>
But the point of the hash update is to take advantage of the unpredictability, however small, in the TRNG output
* cr1901_modern
isn't going to, but nobody explains this shit.
<azonenberg>
You can never make a value less random by hashing it with something else
<cr1901_modern>
That sounds like quite a strong statement, considering in general two different inputs to a hash will have the same output.
<azonenberg>
Think about the simple case
<azonenberg>
Suppose you flip a coin to generate a random bit
<azonenberg>
Ideally, you have equal probability of 0 or 1
<azonenberg>
right?
<cr1901_modern>
yup
<azonenberg>
Suppose the coin is biased instead
<azonenberg>
it returns 1 with 75% probability and 0 otherwise
<azonenberg>
Now, the bad guy can make some predictions about your key and potentially bruteforce your session easier
<azonenberg>
But here's how you can take advantage of that randomness anyway
<azonenberg>
What if you XOR two throws together before using that as your key?
<cr1901_modern>
I'm not doing the binomial dist for that :P
<cr1901_modern>
But it's prob "closer to 50%"
<cr1901_modern>
if I had to naively guess
<rqou>
P(01) == P(10)
<azonenberg>
P(0) = 0.25, P(0,1) = 0.25 * 0.75
<azonenberg>
Then P(1,0) is the same so 2* 0.1875 = 0.375
<azonenberg>
P(0,0) and P(1,1) are the same, so 0.625
<azonenberg>
So 0.375 1, 0.625 0 after the xor
<cr1901_modern>
Interesting!
<azonenberg>
Should be easy to see how as you xor more inputs, no matter how biased the input, the distribution in the long term approaches 50/50
<rqou>
oh you're doing a slightly different thing than what i was doing
<azonenberg>
The point of a hash vs a simple xor is that you a) prevent backtracking and b) spread out randomness between various bits
<rqou>
i saw the "flip two coins" and thought it would be the "how to i get an unbiased coin from a biased coin" problem :P
<azonenberg>
suppose you have the LSB of the ADC stuck or biased differently, middle pretty random, high bits almost always 0
<cr1901_modern>
and backtracking is just finding the CURRENT state given the CURRENT output?
<azonenberg>
in this case, we're talking about internal RNG state not output
<azonenberg>
you don't want a leak of the current state to break past sessions
<azonenberg>
And you want it to recover to an unpredictable value over time if the current state is known to the bad guy
<azonenberg>
e.g. bootup state = constant zeroes
<azonenberg>
So what you'd do is set a min number of iterations after boot before you can use the output
<azonenberg>
to let it reach an acceptable level of randomness
<rqou>
<troll>what about DUAL_EC_DRBG?</troll>
<cr1901_modern>
(Is this still about the ADC?)
<azonenberg>
This is how you'd mix the ADC outputs into the 256-bit state
<azonenberg>
Rather than XORing which would keep biases at fixed bit positions
<azonenberg>
you hash to spread it all out
<azonenberg>
anyway, in the long term this means that your state is a 256-bit value, changing every few ADC reads, that should have near perfect randomness
<azonenberg>
So then you just need to derive an output value from this master seed in such a way that the master seed cannot be predicted from the output
<cr1901_modern>
"you don't want a leak of the current state to break past sessions" <-- I thought you couldn't recover the past state given the current (i.e. "one way")
<azonenberg>
Without hashing, you could exploit the biases in the input
<azonenberg>
Going back to the XOR example
<azonenberg>
if your state is 1 right now
<azonenberg>
and you know the bias is 75% 1s
<azonenberg>
you can say with 75% confidence that the last state was 0
<azonenberg>
But if you use a one-way hash, knowledge of the bias buys you nothing
scrts has quit [Ping timeout: 260 seconds]
<cr1901_modern>
last q for the night "and you know the bias is 75% 1s"... 75% confidence the last state was zero?
<azonenberg>
If your coin is biased 75% 1, 25% 0
<azonenberg>
and you update state as state = coin ^ state
<cr1901_modern>
Oh
<azonenberg>
then there's a 75% chance that the last state was the opposite of the current
<azonenberg>
and 25% that it is the same
<cr1901_modern>
Also, there's Viterbi algorithm to detect hidden markov models. So I wonder if that applies here
<azonenberg>
There's all sorts of ways to detect biases and exploit them
<azonenberg>
but a cryptographically secure hash prevents input bias from being useful to predict the new state
<azonenberg>
Assuming the input entropy is high enough that you can't just bruteforce it
<azonenberg>
if you only add say 8 bits of entropy to the input then it might be bruteforceable :P
<cr1901_modern>
Well this was enlightening. Thanks for not treating me like an idiot :)! I mean that sincerely.
<azonenberg>
But this is why your high-speed outputs use a separate PRNG seeded by the state
<azonenberg>
so that you only sample the state at relatively long intervals after you've got a lot of randomness added to it
<azonenberg>
This is a fairly straightforward and common design, Yarrow for example does something similar
<azonenberg>
as does /dev/random
<rqou>
you know, i just realized i don't see nearly as many crypto prng audits vs other crypto primitives
<rqou>
*cough* *cough* debian
<rqou>
openssl in general
<azonenberg>
do you mean audits of the implementation?
<azonenberg>
or the algorithm
<rqou>
both
<azonenberg>
Because a lot of PRNGs are based on well studied primitives like aes and sha
<azonenberg>
And typically designed such that breaking the PRNG means breaking the cipher/hash
<rqou>
but especially the implementation
<azonenberg>
Which is already a problem a lot of eyes are on
<azonenberg>
this leaves implementation bugs
scrts has joined ##openfpga
<rqou>
it increasingly looks like openssl is by itself a nice footgun
<azonenberg>
Yes
<azonenberg>
I want to make an FPGA-based TLS accelerator that is hard or impossible to misuse
<rqou>
really? eNULL aNULL :P
<azonenberg>
as self-contained as possible
<azonenberg>
lol
<azonenberg>
Yeah, my plan was to pick one common widely supported cipher suite
<azonenberg>
and say that's it, no choices
<azonenberg>
Internal cert validation so you cant screw it up in your app
<rqou>
i was just about to ask about that
<azonenberg>
Don't support lots of fancy features, legacy compatibility, et
<azonenberg>
etc*
<rqou>
how will you handle root updates?
<azonenberg>
Minimum necessary to a functional implementation
<rqou>
what about the revocation clusterf*ck?
<azonenberg>
most likely i'll define some data format for a list of CAs you currently trust
<azonenberg>
OCSP would be nice to support eventually
<rqou>
session resumption?
<azonenberg>
probably not going to do a lot of that
<azonenberg>
or heartbeats, or re-negotiations
<azonenberg>
bare bones so there's less places to go wrong
<azonenberg>
formal verification would be nice too
<rqou>
but then it'll be _slow_ and people will complain :P
maaku has quit [Read error: Connection reset by peer]
maaku has joined ##openfpga
<rqou>
btw how come TLS doesn't by itself support any kind of strict transport security/public key pinning options?
<rqou>
everybody just added this to http and didn't bother with anything else that uses TLS
Bike has quit [Quit: n]
scrts has quit [Ping timeout: 260 seconds]
<azonenberg>
Very good question
<azonenberg>
When i get around to TLS-ifying Splash there won't even *be* a nonsecure option
<azonenberg>
As far as pubkey pinning, i'll probably require you to provide a CA cert that it verifies against
<azonenberg>
and distrust all others
scrts has joined ##openfpga
scrts has quit [Ping timeout: 245 seconds]
scrts has joined ##openfpga
Ardeshir has joined ##openfpga
Ardeshir has quit [Quit: Leaving]
X-Scale has joined ##openfpga
maaku has quit [Quit: No Ping reply in 180 seconds.]
maaku has joined ##openfpga
mzpx has joined ##openfpga
tecepe has quit [Ping timeout: 240 seconds]
x01zz has joined ##openfpga
mzpx has quit [Ping timeout: 258 seconds]
tecepe has joined ##openfpga
kristianpaul has quit [Quit: Lost terminal]
kristianpaul has joined ##openfpga
kristianpaul has joined ##openfpga
kristianpaul has quit [Changing host]
x01zz has quit [Ping timeout: 265 seconds]
mzpx has joined ##openfpga
mzpx has quit [Ping timeout: 248 seconds]
mzpx has joined ##openfpga
mzpx has quit [Ping timeout: 260 seconds]
mzpx has joined ##openfpga
mzpx has quit [Ping timeout: 268 seconds]
mzpx has joined ##openfpga
x01zz has joined ##openfpga
mzpx has quit [Ping timeout: 260 seconds]
pie_ has quit [Quit: Leaving]
pie_ has joined ##openfpga
x01zz has quit [Ping timeout: 258 seconds]
mzpx has joined ##openfpga
mzpx has quit [Ping timeout: 250 seconds]
mzpx has joined ##openfpga
<pointfree>
So, the hseg_b and hseg_f do not respectively stick to even and odd bit offsets. Therefore, there must be separate _b and _f HS bytes as there were with vsegs. Btw, the _b and _f suffixes refer to the first and second columns in FIG16 respectively.
mzpx has quit [Ping timeout: 268 seconds]
mzpx has joined ##openfpga
tecepe has quit [Remote host closed the connection]
amclain has joined ##openfpga
mzpx has quit [Read error: Connection reset by peer]
Bike has joined ##openfpga
tecepe has joined ##openfpga
tecepe has quit [Ping timeout: 256 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
tecepe has joined ##openfpga
digshadow has quit [Ping timeout: 250 seconds]
digshadow has joined ##openfpga
massi has quit [Remote host closed the connection]
<digshadow>
azonenberg: haven't heard from ylamarre in a while. Do you know if they are still interested in openfpga stuff?
<azonenberg>
No i have not
dingbat has quit [Remote host closed the connection]
dingbat has joined ##openfpga
dingbat has quit [Read error: Connection reset by peer]
clifford has quit [Ping timeout: 265 seconds]
tecepe has quit [Ping timeout: 260 seconds]
dingbat has joined ##openfpga
tecepe has joined ##openfpga
m_w has joined ##openfpga
dingbat has quit [Quit: Connection closed for inactivity]
<rqou>
hey whitequark since i see you complaining about lack of bsd licenses
<rqou>
how possible would it be to convince sb0 to make softusb_navre.v (from milkymist) not gplv3?
<rqou>
afaik gplv3 on hdl has weird and annoying effects
<rqou>
unfortunately afaik there's no good copyleft hdl license
<azonenberg>
rqou: basically everything copyleft is, if one ip core is license X
<azonenberg>
the whole soc is
<azonenberg>
unless you had partial reconfig and loaded the gpl'd core separately
<azonenberg>
that miiight qualify as a separate "executable"
<azonenberg>
but you might need that lpgl to be kosher
<rqou>
but there's also so-called "weak copyleft" like MPL
<rqou>
afaik MPL applies to individual files
<rqou>
also, as far as i understand it, you can't mix gplv3 ip cores with blob ip cores
<azonenberg>
Yeah
<rqou>
so you can't use e.g. the xilinx MIG or pcie block with a gplv3 ip core
<rqou>
wtf vhdl allows operator overloading
<rqou>
apparently the vhdl spec explicitly forbids vhdl files from being utf-8
<rqou>
The only characters allowed in the text of a VHDL description (except within comments—see 15.9, and
<rqou>
within text treated specially due to the effect of tool directives—see 15.11) are the graphic characters and
<rqou>
format effectors. Each graphic character corresponds to a unique code of the ISO eight-bit coded character
<rqou>
set (ISO/IEC 8859-1:1998) and is represented (visually) by a graphical symbol.
scrts has quit [Ping timeout: 256 seconds]
<lain>
yeeeup
<azonenberg>
Will that change in future vhdl at all?
<azonenberg>
i havent checked the verilog LRM for that