<wpwrak>
yeah, a bare password is very unsafe. you really need to rate-limit decryption attempts.
<wpwrak>
then use the password to unlock a long string of random bits
<whitequark>
larsc: what
<whitequark>
wpwrak: so, bcrypt with salt is all you need
<whitequark>
(bcrypt is a hash algo specifically designed to be slow when implemented on FPGA)
<kyak>
so.. don't use dictionary words and do use long passwords?
<larsc>
kyak: and use something a human wouldn't think of
<whitequark>
kyak: well, try to remember 30 symbols of alphanumeric garbage and tell me how well it works
<whitequark>
it's fine if you have a password safe, but you have to unlock *that* with something.
<kyak>
whitequark: remember it once, probably use some mnemonics, and then use variations of that
lilvinz has quit [Ping timeout: 265 seconds]
<larsc>
if they steal your safe from you computer all is probably lost anyway
lilvinz has joined #qi-hardware
<wpwrak>
keep the master secret in an MCU. it
<whitequark>
kyak: still too hard. especially if you want to rotate it, which is a Good Idea.
<wpwrak>
's not so easy to get things out of these
<whitequark>
I cannot reliably type in even a mixed-case passphrase
<kyak>
whitequark: no argue with that
<whitequark>
larsc: if they can decrypt it.
<whitequark>
bcrypt with a good passphrase will give you at least enough time to change every password you have there.
<larsc>
whitequark: I meant if they have access to your machine they can probably just sniff when you enter the passphrase to unlock the safe
<kyak>
what if your password safe is encrypted twice, just for fun? :) I imagine those guys spending resources on decrypting the first wrapper, only to find the second one.. And they don't really know if there's going to be another one
<whitequark>
larsc: if they have access to your machine, all is lost anyway
<whitequark>
I was thinking along the lines of "stolen notebook"
<whitequark>
which you can actually defend against.
<whitequark>
kyak: security through obscurity. known to not work
<larsc>
it helps against driver by attacks
<kyak>
whitequark: that's not obscurity
<rjeffries>
kyak did you read the damn article? very (!) long passphrases that have been partially onfusicated and are way way off teh beaten path are vulnerable.
<larsc>
drive
<whitequark>
kyak: oh, so you mean to make them spend more resources?
<whitequark>
bcrypt already includes that, with a factor you can adjust
<kyak>
rjeffries: these were dictionary words, that's the root cause if i read correct
<whitequark>
wpwrak: last time I checked, you could erase the lock bits with a bit of acid and black electric tape :p
<whitequark>
(on some PICs)
<rjeffries>
agree that totally random longish passwords are good. also impossible to memorize
<kyak>
whitequark: yeah, for spending more resources and making it unclear how much more resources they would need
<kyak>
demotivate them :)
<rjeffries>
wpwrak will anelok generate passwords? I forget the specs. ;)
<wpwrak>
whitequark: yes, at some point in time, you want to make your own crypto chip, with a few extra layers
<wpwrak>
rjeffries: yup. it the idea is that it can propose passwords
<whitequark>
kyak: how would you know when to stop if you yourself mistyped your password?
<whitequark>
with the scheme you're proposing, it seems that the process will never end
<rjeffries>
wpwrak: cool. useful.
<wpwrak>
(based on an alphabet the user selects and a suitable string of random bits the device generates)
<whitequark>
though, that actually can play in your advantage
<whitequark>
wpwrak: shut up and take my money already
<kyak>
whitequark: you know how many layers this onion has
<wpwrak>
:)
<rjeffries>
wpwrak: there *is* a market for your gadget. lol
<rjeffries>
you already sold qty = 2
<kyak>
this article was written by wpwrak's marketing department! the truth is reveled!
<rjeffries>
by the way you current industrial design is rather nice. You've tapped your inner Jonny Ives.
<wpwrak>
;-)
<rjeffries>
s/you/your/
<qi-bot>
rjeffries meant: "by the way your current industrial design is rather nice. You've tapped yourr inner Jonny Ives."
<rjeffries>
I see one needs to include a trailing space to avoid expanding embedded substring
<wpwrak>
maybe i should snap another picture. i now also have the display working "standalone". gave a bit of trouble. first i had one pin shorted, which caused the device to burn up to about 500 mA if it let it, then i had inverted one signal in the schematics (when going from the display-only prototype to the full device prototype) and faithfully copied that into the firmware, making communication with the display fail.
<wpwrak>
i then though that maybe i had fried the display and replaced it. only then did i find the bug. so now i have a working display, plus one that's a bit tattered of unknown state
<wpwrak>
ah, and the wheel is working, too
<rjeffries>
round and round it goes. where it stops, nobody knows. Indiegogo?
<wpwrak>
i'd hope it doesn't stop there :)
<rjeffries>
you have something against crowdfunding?
<wpwrak>
not at all. but it it _stops_ there, that would mean failure, wouldn't it ?
<rjeffries>
wpwrak: agreed.
<rjeffries>
wpwrak is it fair to assume that anelok is independent of OS on the target PC that interacts with the internet? in other words it is simply a USB device that presents a (I think?) HID USB to teh host, be that Linux or Windows or (of interest to me) Chromeos?
<wpwrak>
at that level, yes. there would be more advanced functions that would create additional dependencies, though. e.g., pre-selecting a password entry, pc-based password management, and such
FrankBlues has joined #qi-hardware
<eintopf>
hi :-)
<FrankBlues>
Howdy!
<wpwrak>
hmm, does anyone know vflib ? it seems that it should be able to convert fonts into bitmaps. alas, while it lists a great many fonts, it then don't find them
<viric>
freetype also converts fonts into bitmaps :)
<wpwrak>
are there command-line tools to do that ?
<wpwrak>
(i want bitmaps i can use in my program. not bitmaps on the screen :)
<larsc>
make photograph of your screen and then scan the result ;)
<wpwrak>
yeah, there's half a dozen programs to visualize fonts. then xwd, ... ;-)
<viric>
wpwrak: imagemagick can render text I think
<viric>
maybe you can use 'conjure' or soemthing like that to render whatever you want
<wpwrak>
ah, should have thought of that. imagemagick can do kinda everything :) let's see ...
<larsc>
I think there are dozens of programs out there that generate you for example a 16x16 glyphs bitmap
<viric>
if you want small fonts, you better get a bitmap font of that size, instead of rendering a vector one.
<wpwrak>
yes, i suppose there are. the issue is finding them ;-)
<wpwrak>
hmm, and imagemagick.org doesn't load :-(
<wpwrak>
-draw <something> seems to be the magic word
<wpwrak>
nice. if you use it with "convert", it works. if you use it with "display", it fails silently.
<viric>
magick.
<wpwrak>
hmm, not too great results, though. alpha-blends then dithers them :-(
<wpwrak>
guess i need a more specialized tool ...
<viric>
it's a hell to get monochrome from vector fonts
<viric>
When I want monochrome fonts, I use bitmap fonts, not vector
<viric>
even vector rendering to grayscale is full of tricks; antialiasing, subpixel rendering, hinting, ...
<wpwrak>
maybe i should just decode the X .pcf files ...
<rjeffries>
wpwrak: I still hope when you refine user interface you consider displaying a larger image of the currently selected character something like 2x or 3x magnification of current character would so totally rock.
<wpwrak>
bloody complex, though. where's version v1.0 of all this ? :(
<wpwrak>
rjeffries: naw, i'd try to avoid such weird magnifying tricks. just use a readable font ;)
<viric>
X pcf files are bitmap fonts. Das ist gut
<viric>
I guess imagemagick can only render fontconfig fonts, thus, vector.
xiangfu has quit [Quit: leaving]
<wpwrak>
hmm .. -misc-fixed-bold-r-normal-*-15 ? about 10x8 pixels for "normal" characters ...
<wpwrak>
let's use the power of xwd and bitmap
<wpwrak>
... and, say, xmessage
<viric>
the lazy fox ...
rjeffries has quit [Ping timeout: 250 seconds]
<wpwrak>
or maybe just a nice xterm ...
<mth>
wpwrak: python imaging library can handle converted bdf fonts, according to its docs
dos1 has joined #qi-hardware
<wpwrak>
thanks ! i'll try the ultra-traditional approach first ... let's see how it goes :)
<mth>
and now many 2D functions do you really need nowadays? alpha blended blits is probably what is needed most
<larsc>
yea, solid rect fill isn't that widely used anymore ;)
<wpwrak>
block copy ? for text ...
<mth>
that's a blit with the alpha test disabled
<larsc>
overlays are quite handy
<mth>
rect fill isn't hard to implement in case you need it: you just specify a source that is a single color
<mth>
overlays don't play that well with compositing window managers afaik
<larsc>
neither does no 3d accleration
<mth>
you could to a compositing WM with just fast alpha blends, I think
<mth>
s/to/do/
<qi-bot>
mth meant: "you could do a compositing WM with just fast alpha blends, I think"
<roh>
mth: true. but most drivers dont expose any alpha-surface 2d ops anymore
<mth>
yes, you might have to do both the software and hardware then
<roh>
so in the end one uses the 3d units for that... simply because thats the only ones left.
<mth>
but only at the system level; you could use the same interfaces towards the applications
<roh>
they even removed the video-units on most hw... old radeons had a blitter optimized for video overlays.... nowadays one needs to use a texture on the 3d unit.. a shader
<roh>
mth: what interface? x11 doesnt support alpha surfaces
<roh>
classic x11 apps which do alpha do it in-app and fetch the back of the window and the rerender and draw transparency in sw while the expose event comes through
<mth>
it doesn't? how does KDE make rounded window corners then?
<roh>
sw rendering
<roh>
the new stuff is compositing with alpha and apis which arent anymore network transparent afaik
<mth>
that's how it worked before compositing, I think they use an extension now to push buffers with an alpha component
<mth>
although I haven't read the code in question, so it's just an impression from blog posts etc
<larsc>
you can provide a shape for your window
<larsc>
see e.g. xclock
<roh>
its not 'straightforward' or 'nice'
<roh>
larsc: yep. but thats only hard corners. no alpha
<roh>
basically a mask
<mth>
network transparency and pretty windows seem to be mutually exclusive under X11
<roh>
forget x11...
<roh>
wayland/whatever comes beyond....
<mth>
afaik the reference implementation of Wayland uses EGL, but the protocol doesn't rely on any 3D functionality
<mth>
so if you're design your own 2D GPU, you could run Wayland on it just fine
<roh>
nothing on a 3d unit forces you to use more that 2 dimenstions
<mth>
s/you're/you'd/
<qi-bot>
mth meant: "so if you'd design your own 2D GPU, you could run Wayland on it just fine"
<roh>
after all its just doing triangles ;)
<mth>
yes, if you have a 3D engine, then by all means use it
<mth>
I was just thinking of what the minimum functionality would be for a GPU to be useful for 2D apps
<roh>
not more than a matrox G200/G450 could do. just faster and with alpha surfaces and i'm happy
<mth>
since a lot is handled by client side rendering nowadays, composing the final frame is really where the hardware acceleration can still make a difference
wolfspraul has quit [Ping timeout: 268 seconds]
FrankBlues has quit [Remote host closed the connection]
<larsc>
but most clientside rendering is done with libs like cairo, which can have acceleration backends
panda|x201 has joined #qi-hardware
panda|x201 has quit [Ping timeout: 264 seconds]
panda|x201 has joined #qi-hardware
wej has quit [Ping timeout: 245 seconds]
arossdotme has quit [Ping timeout: 245 seconds]
arossdotme has joined #qi-hardware
wej has joined #qi-hardware
arossdotme has quit [Ping timeout: 245 seconds]
arossdotme has joined #qi-hardware
<apelete>
Hi there
<apelete>
larsc mth: I built the nop transceiver driver into the kernel and got rid of the "unable to find transceiver of type USB2 PHY" error message during boot -> http://paste.debian.net/54548/
<apelete>
but I found it strange to have these two messages before the probe is finished (before glue layer is registered):
<apelete>
[ 1.230000] musb-jz4740: hello world!
<apelete>
[ 1.240000] musb-jz4740: goodbye cruel world
<apelete>
these are from init and exit respectively
kilae has quit [Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]]
<apelete>
ah, I see, it's because musb_core seems to be calling musb_platform_init() during the probe. from musb_core.c:
<apelete>
/* The musb_platform_init() call:
<apelete>
* - sets the musb->isr
<apelete>
* - adjusts musb->mregs
<apelete>
* - may initialize an integrated tranceiver
<apelete>
* - initializes musb->xceiv, usually by otg_get_phy()
<apelete>
* - stops powering VBUS
<apelete>
*
<apelete>
* There are various transceiver configurations. Blackfin,
<apelete>
* DaVinci, TUSB60x0, and others integrate them. OMAP3 uses
<apelete>
* external/discrete ones in various flavors (twl4030 family,
<apelete>
* isp1504, non-OTG, etc) mostly hooking up through ULPI.
<apelete>
*/
<apelete>
so I guess I need to complete the init function now
<apelete>
larsc mth: don't really know what should go into init though.
<apelete>
I think: clock setting is a sure bet, mregs is not needed according to what we discuss last night, don't know what to do about isr, transceiver should be ok now since I settled for nop transceiver, and don't know about vbus
<apelete>
s/discuss/discussed/
<qi-bot>
apelete meant: " I think: clock setting is a sure bet, mregs is not needed according to what we discussed last night, don't know what to do about isr, transceiver should be ok now since I settled for nop transceiver, and don't know about vbus"
<apelete>
larsc mth: any advice about all those ?
arossdotme has quit [Remote host closed the connection]
<mth>
apelete: the isr is set in the jz4770 glue, but I don't really know what it does there; I left that code as it was
<apelete>
mth: do you think I could reuse that isr code it for jz4740 ?
<mth>
I have no idea
<mth>
it's probably worth reading it, but copy-paste may or may not work
<mth>
it would be useful to compare it to the interrupt handler of the old UDC driver
<apelete>
okay. I'm rebasing my work on top of jz-3.11 first (was on jz-3.9), will take a look at it then