02:10 <cyrozap> nats`: In my experience, I've had some trouble flashing ESP8266 dev boards with onboard CH340, but no trouble flashing the ones with SiLabs CP2012. So it's probably mostly fine, but unless you're building 1000's of units, I'd think the small per-unit savings isn't worth the trouble of using a possibly-somewhat-buggy part.

02:33 <rqou> right, this reminds me that "program a cortex-m0 to pretend to be an ft232" is still on my todo list

03:23 <pie_> so i finally cleared my smaller desk, not that either of them are particularly big, and got out my electronics stuff

03:23 <pie_> woo i made a led+switch lmao

03:23 <pie_> forgot to order switches from aliexpress though so i cannibalized a keyboard switch from a sample kit

04:01 <cyrozap> rqou: While that's an interesting project (and one I've thought of taking on myself), what would be the point? I haven't seen an M0 micro with USB and a UART that was cost-competetive with any dedicated USB-serial ICs.

04:02 <rqou> er, iirc i had looked for one that was competitive with the ftdi asic

04:02 <rqou> but yeah, it's not quite competitive with the other clones if you just need usb-serial

04:02 <rqou> i was also going to cram it other functionality like usb-spi and "random bootstrapping stuff"

04:02 <cyrozap> Ah, I see

04:03 <cyrozap> Have you seen the Cypress USB-Serial bridge ICs?

04:03 <rqou> no?

04:03 <cyrozap> http://www.cypress.com/products/usb-serial-bridge-controller

04:05 <cyrozap> The high-end one has two serial ports that can be configured for SPI and I2C, and one of the ports also supports ~400 kHz JTAG. Cost for that chip is $2.50.

04:08 <cyrozap> For the plain USB-serial mode, it uses CDC-ACM so it can be used out-of-the-box on OS X and Linux. For everything else, there's a really awful library that I made slightly less awful (and also got it to compile on Windows): https://github.com/cyrozap/libcyusbserial

04:22 <pie_> why is jtag so slow btw?

04:30 <cyrozap> pie_: Because the chip is just an 8-bit microcontroller (with Cypress firmware) bit-banging JTAG.

04:32 <pie_> i meanin general

07:08 <cyrozap> pie_: Normal signal integrity reasons. Many chips only support JTAG clocks up to a few tens of megahertz, meaning the theoretical max transfer speed is going to be only a few megabytes per second (ignoring protocol overhead and state machine transitions). Most reasonably-priced adapters can't even go that fast, so you're limited to one megabyte/s or less. Finally, even when both the chip and the

07:08 <cyrozap> adapter support high speeds, you need to make sure the cable your using is as short as you can tolerate, otherwise you'll start having signal integrity problems.

07:19 <rqou> alternatively you can be like Intel and tunnel JTAG over a USB SS PHY

09:27 <rah> I'm selling a GTA04 phone bundle in case anyone is interested: http://settrans.net/~rah/gta04-sale/gta04-bundle-for-sale.txt

09:28 <rqou> wow unfortunately for me that's a lot of money and i have enough random crap already

09:33 <rah> rqou: so make me an offer? :-)

09:33 <rah> rqou: how about we exchange junk? :-)

09:33 <rqou> i need to inventory my junk first :P

09:33 <rqou> also, i'm in the US so i don't know how well shipping works

09:33 <rqou> don't want to accidentally create a byuu here

09:46 <nats`> cyrozap there will be 2 or 3 unit maximum

09:46 <nats`> it's more a question of driver and those crap

09:46 <rqou> i heard that on windows the cdc acm driver sucks

09:47 <rqou> and on osx afaik all usb-serial drivers suck

09:47 <rqou> (on linux IME all usb-serial drivers kernel-side just work)

09:47 <nats`> the CDC driver doesn't suck in itself

09:47 <rqou> (modemmanager sucks though)

09:47 <nats`> it's more they implement it strictly and lot of CDC device doesn't answer corectly to the feature request

09:48 <nats`> so they don't answer with 0000 but with something like 0001

09:48 <nats`> need to find back the example we had at work

09:48 <rqou> there was something about how win10 fixed something in the cdc acm driver for arduino?

09:51 <nats`> https://msdn.microsoft.com/en-us/library/windows/hardware/ff538820(v=vs.85).aspx

09:51 <nats`> if you don't respect exactly those code it'll never show up the COM serial port

09:52 <rqou> there was something about the cdc acm driver somehow getting stuckk

09:52 <rqou> idk

09:52 <rqou> in general drivers just suck all around

09:53 <nats`> https://msdn.microsoft.com/en-us/library/windows/hardware/dn707976(v=vs.85).aspx

09:54 <rqou> "Also usbser.sys has been completely re-written in WDF, improving its overall reliability as well incorporating new features for power management"

09:54 <nats`> and it asks for a specific class

09:54 <nats`> otherwise it'll wait for a manufacturer driver

09:54 <rqou> but they did also bugfix the cdc driver

09:54 <rqou> in general the linux one has been much more tolerant of breaking the rules

09:55 <rqou> meanwhile on the other extreme macos _insists_ cdc devices are modems

10:28 <pie_> cyrozap, thanks

10:33 <nats`> you have the same with ubuntu

10:33 <nats`> soft guyz here spend 2 days on one product

10:33 <rqou> but you can at least uninstall modemmanager

10:33 <nats`> they though their embedded usb stack was bloated

10:34 <nats`> but nop it was ubuntu sending crap automagically to CDC device

10:34 <rqou> honestly at this point i don't understand why modemmanager even speaks to normal serial ports

10:34 <rqou> i would be ok with one that only spoke qmi

14:03 <rqou> HOLY SHIT https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html?m=1

14:06 <whitequark> holy shit?

14:06 <whitequark> sha1 was broken in 2005

14:06 <whitequark> https://www.schneier.com/blog/archives/2005/02/sha1_broken.html

14:06 <rqou> but this is a true collision

14:06 <rqou> not a freestart collision or a research paper

14:07 <rqou> as in, two different pdf files with the same hash

14:07 <rqou> afaik tghe 2005 paper is just an algorithm for producing such a collision and not a collision itself?

14:12 <whitequark> it's not really a "holy shit" moment if it was predicted over a decade ago

14:12 <rqou> alright, fine :P

14:12 <rqou> also a freestart collision was announced a number of months back

14:25 <lain> hm

14:25 <lain> typo in google blog

14:25 <lain> "Today, 10 years after of SHA-1 was first introduced"

14:25 <lain> two typos ("after of"?) and 10 years

14:25 <lain> it's uhhh been around a lot longer than a decade

14:26 <qu1j0t3> they were excited.

14:26 <lain> hehe

14:27 <lain> hm

14:27 <lain> interesting though, that they were able to do 2^63 hashes for that

14:27 <lain> that is a crapton of hashes

14:28 <rqou> wait

14:28 <lain> and slightly fewer than the 2005 break would suggest were required, but that could easily just be luck

14:28 <rqou> this means that 64-bit encryption keys are breakable

14:28 <rqou> at least by google

14:28 <rqou> i guess that's not too surprising though

14:29 <rqou> hmm, des is 56-bit keys

14:29 <lain> it will be interesting to see what it takes to accelerate memory-hard problems

14:29 <rqou> 2^63 is only 128x as hard

14:30 <rqou> and deep crack did 2^56 over a decade ago

14:35 <rqou> huh, debian sid's qemu-user-static no longer needs hax to make dhclient work