x01zz has quit [Remote host closed the connection]
<rqou> TIL this massive footgun/unfeature exists: http://man7.org/linux/man-pages/man3/malloc_get_state.3.html
<pie_> its in C! of course its a footgun!
<pie_> jk
tecepe has quit [Remote host closed the connection]
tecepe has joined ##openfpga
uwe_ has quit [Ping timeout: 240 seconds]
uwe_ has joined ##openfpga
digshadow has quit [Quit: Leaving.]
<azonenberg> rqou: wtffff
<rqou> thanks emacs
<azonenberg> lol
<azonenberg> Well i guess since Emacs Makes Any Computer Slow they had to optimize somehow...
<azonenberg> but wow, they literally burn a raw memory image of all of the stuff to disk?
<azonenberg> and de-serialize it?
<whitequark> yes.
<whitequark> and they also have to bootstrap it iirc
<azonenberg> yeah i saw
<azonenberg> app-level hibernation, srsly?
<pie_> dont run emacs as root
digshadow has joined ##openfpga
<lain> s/ as root//
<pie_> hrhr
<pie_> i found the troll ;D
<pie_> jk
* pie_ flattens lain under an emacs manual
* qu1j0t3 found two trolls
<lain> hehe
<pie_> yeah qu1j0t3 stop trolling ;P
* qu1j0t3 it;s not trolling if you do it in emotes/actions see troll manual §7.88.12
* qu1j0t3 never saw the troll manual that was a total guess
* qu1j0t3 doesn't own a copy heck i'm sure it doesn't exist
<pie_> rule 1 of the troll club
digshadow1 has joined ##openfpga
digshadow has quit [Read error: Connection reset by peer]
digshadow has joined ##openfpga
digshadow1 has quit [Read error: Connection reset by peer]
maaku has quit [Quit: No Ping reply in 180 seconds.]
maaku has joined ##openfpga
carl0s has joined ##openfpga
<qu1j0t3> well i guess i'm expelled now
_whitelogger has joined ##openfpga
carl0s has quit [Remote host closed the connection]
amclain has quit [Quit: Leaving]
<pointfree> cyrozap: I've enumerated some VS/vseg mappings using my psoc-routing-formulas, and sliced and sorted them by register offset and by index: http://hub.darcs.net/pointfree/psoc-hs-vs-hv-tiles/browse/top_f-top_b-bot_f-bot_b-mapping.md
<pointfree> This pattern is about how the 24 lines in FIG6 connect to the 24 lines in FIG16 and such.
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
DocScrutinizer05 has quit [Read error: Connection reset by peer]
DocScrutinizer05 has joined ##openfpga
<cr1901_modern> azonenberg: How the hell did you find this http://www.fun.co.jp/english/pdf/twin.pdf
<azonenberg> cr1901_modern: Google-fu
<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
<azonenberg> cr1901_modern: link?
<azonenberg> rqou: lol
<cr1901_modern> https://www.youtube.com/watch?v=ypNPxwnppU0 Listen for more than 9 seconds :)
<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> this made sense back in the 80s or so
<rqou> but then the 90s happened and all of these addresses got onto spam mailing lists
<azonenberg> rqou: lol
<rqou> and then the 2000s happened and everyone moved to webmail
<rqou> and then the 2010s happened and everyone moved to smartphone apps
<rqou> and at this point in time almost nobody knows these accounts exist anymore and almost nobody knows how to even access them
<azonenberg> rqou: lol
<rqou> you had to use things like "pine"
<rqou> :P
<azonenberg> Hey, i used alpine as my main mail client for a hwile
<azonenberg> while*
<azonenberg> Post 2010
<cr1901_modern> Yikes, this is grim. I love it!
<rqou> at some point the staff added imap and roundcube
<azonenberg> The main thing that drove me to thunderbird (with a short stop in Evolution) was PGP support
<azonenberg> or lack thereof
<rqou> but nobody of my generation knows how to use imap either :P
<cr1901_modern> It reminds me of Melancholy Man by The Moody Blues
<azonenberg> cr1901_modern: this guy does a massive range of styles, almost all based on games and movies
<cr1901_modern> (not that anyone knows what that song means)
<cr1901_modern> Lol, this is quite silly (and cute)
<rqou> interestingly, the UCB dorms have landline connections still (and you are required to pay for it)
<rqou> i don't know of anyone who used them, but one day i saw one of the wiring closets unlocked
<azonenberg> cr1901_modern: This one is darker https://www.youtube.com/watch?v=RzlGgybMPn8&index=103&list=PL90229471516D05ED but I like it too
<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
<rqou> no idea, this is the 2008 lrm
<rqou> which i believe is the latest