Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
<kristianpaul>
how long until a zynq based nettop/netbook?
fire__ has quit [Read error: Operation timed out]
<kristianpaul>
well basically a zedboard could be used as a nettop..
fire__ has joined #qi-hardware
antgreen has joined #qi-hardware
urandom__ has quit [Quit: Konversation terminated!]
jluis_ has quit [Ping timeout: 260 seconds]
<wolfspraul>
kristianpaul: yes, that'd be nice, no? (a zynq-based computer...)
<wolfspraul>
keep an eye open for it and if you see something let us know...
jluis has joined #qi-hardware
<wolfspraul>
xilinx recently acquired petalogix (petalogix.com), presumably to offer linux/embedded solutions around the zynq
<xiangfu>
it's using zynq 7010, running Ubuntu OS.
<wolfspra1l>
xiangfu: oh, nice
<wolfspra1l>
I think I saw this before but didn't pay attention, have to check again
<wolfspra1l>
and it seems they got their 750k usd that they were aiming for :-)
<wolfspra1l>
they promised to "open everything" after getting those 750k usd, so what stops them now? we will find out soon :-)
<wolfspra1l>
maybe that's a new open source business model - open blackmail
<wolfspra1l>
"I will open these unbelievably valuable 'things' after I receive XXX USD"
<wolfspra1l>
but anyway, looks like a good project - thanks!
porchao has quit [Quit: Leaving...]
porchao has joined #qi-hardware
<wolfspra1l>
Q: "will you open source the epiphany chips" A: not initially, but considered later
<wolfspra1l>
I was thinking a bit more about artix vs. zynq, and realized the cost issue
<wolfspra1l>
an xc7a100 costs 140 USD on digikey now, vs. 240 USD for the zynq (with 85k fabric cells compared to 100k for the xc7a100)
<wolfspra1l>
that's 100 USD more for the ARM core
LunaVorax has quit [Remote host closed the connection]
<wolfspra1l>
we can divide digikey prices roughly in half, meaning xc7a100 = 70 USD, xc7z7020 = 120 USD
<wolfspra1l>
still 50 USD more
<viric>
wolfspra1l: I remember a game writer that promised to give the games open source, if he got donetions over some limit. Didn't succeed, and then continued selling closed source.
<viric>
- he wrote that video game about making linux distributions
<viric>
Isn't the M1 running uclinux? Why the uclinux web page doesn't cite M1?
<larsc>
it'srunning linux
nerd has quit [Quit: WeeChat 0.3.9]
kilae has joined #qi-hardware
kilae_ has joined #qi-hardware
kilae has quit [Ping timeout: 245 seconds]
kilae_ has quit [Client Quit]
<whitequark>
ah, was just going to write about parallella
<whitequark>
wolfspra1l: if the zynq chip costs $240, how are they able to sell the complete boards for $99?
<whitequark>
well, they at least have the complete reference manual published
<whitequark>
that chip has an interesting topology. inter-core write transactions are 16x more efficient than read ones.
jluis has quit [Ping timeout: 260 seconds]
jluis has joined #qi-hardware
<lekernel>
whitequark: "PSoC Creator is a Windows-based IDE. However, I exclusively use Macs"
<lekernel>
*grin*
<lekernel>
whitequark: are you coming to EHSM?
<whitequark>
lekernel: as I've said already, I considered that a toy, so wine would be fine. but it turned out to be a completely un-fun toy.
<whitequark>
lekernel: EHSM?
<whitequark>
hm, Dec 28, Berlin...
wej has quit [Ping timeout: 272 seconds]
<whitequark>
seems interesting. I wonder if I could get a visa soon enough.
jluis has quit [Ping timeout: 260 seconds]
<lekernel>
if you need an invitation letter or such, I can produce one...
<whitequark>
thanks! I'll consider the options I have.
wej has joined #qi-hardware
<whitequark>
... and if adapteva just published the sources, I could load it to my M1 and use it right now. sigh.
dandon has quit [Quit: .]
kristianpaul has quit [Ping timeout: 272 seconds]
kristianpaul has joined #qi-hardware
kristianpaul has quit [Changing host]
kristianpaul has joined #qi-hardware
<viric>
this EHSM looks very interesting
wej has quit [Ping timeout: 260 seconds]
<wpwrak>
whitequark: (un-fun toy) psoc or their IDE ?
<whitequark>
wpwrak: the psoc-specific parts of toolchain
<whitequark>
apparently there's no way to compile the PLD bitstream except for that .NET IDE
wej has joined #qi-hardware
<viric>
mono can run many .net things
<wpwrak>
well, the chip is completely documented at the register level. so you can just roll your own ;-)
<whitequark>
viric: it requires native components
<whitequark>
the ide won't run under either mono@linux, mono@wine or dotnet@wine
<viric>
ok
<whitequark>
and I'm not going to waste my time by developing the whole application under windows. it's just unproductive.
<wpwrak>
they help you to stay pure ;-)
<whitequark>
wpwrak: roll my own... that's at least a year of work to make a good toolchain
<whitequark>
and the chip is too expensive for real projects anyway
<wolfspra1l>
whitequark: i don't fully understand the parallella thing either, need to read a bit more
<wolfspra1l>
maybe 99 USD is just for the board containing their newly made asic
<wolfspra1l>
which is what they need the 750k usd for
<whitequark>
wolfspra1l: yeah, that's for the board with ASIC
<wolfspra1l>
(and which won't be opened either)
<wolfspra1l>
so they found a way to offload the risk of an asic tape-out via kickstarter - great! :-)
<wolfspra1l>
there should be more such projects, wherever the chips go in the end...
<wpwrak>
whitequark: yeah, they made their new psocs very nice from a technical point of view, but also quite ugly from a price point
<whitequark>
wolfspra1l: on one hand, they have a really really nice and well thought out ISA (I just read the reference manual), and I'm fairly certain for the completely open toolchain
<whitequark>
on the other one, the chips will probably never be open
<wpwrak>
you mean at the verilog level ?
<whitequark>
yup
<wpwrak>
okay, that would be asking for a lot
<whitequark>
indeed.
<wpwrak>
but when i looked at them a few years ago, they had a very nice reference manual that explained every last bit of "FPGA" state. (among a ton of other things)
<whitequark>
but it's a coprocessor. it doesn't have as much value as it could unless it can be incorporated in other designs
<wpwrak>
so until wolfgang publishes his results, these psocs are probably the best-documented non-trivial programmable logic in the world :)
<larsc>
wpwrak, whitequark: I think you are talking about differnt chips
<whitequark>
wpwrak: oh, you're talking about PSoCs
<wpwrak>
ah, and you about the parallela critter :)
<whitequark>
PSoC is what should have actually been at the heart of arduino. it's a perfect prototyping platform.
<whitequark>
maybe when freeSoC completes their job, someone will write a good toolchain for it
<wpwrak>
yeah, good point
e2580 has joined #qi-hardware
<larsc>
something on the scale of PSoC might be a good starting point for a kind of opensource fpga
kristianpaul has quit [Ping timeout: 260 seconds]
<e2580>
hi
panda|z has joined #qi-hardware
<panda|z>
xiangfu: yo ;)
<e2580>
Anyone interested in a sneak peek at a hardware based security device we are about ready to release?
<e2580>
details on the info page. i can answer questions if you have any
<larsc>
e2580: can you give a short overview/introduction?
<e2580>
the device is a hardware encrypted storage device
<e2580>
in short
<e2580>
for details the website lists the features and functions on info page mostly
<e2580>
the video is not quite ready yet...
kristianpaul has joined #qi-hardware
kristianpaul has quit [Changing host]
kristianpaul has joined #qi-hardware
<panda|z>
e2580: OK, sounds like to protect your data on SD card?
<panda|z>
e2580: so data on those 2 SD card is not accessable without this device?
<e2580>
sd card is used for the storage of the data
<e2580>
the data on the sd cards is aes256 encrypted, you will not be able to decrypt it without the device
<panda|z>
e2580: OK, I see, it's cool, but probably I have no chance to use it :)
<e2580>
there will be suppliers outside the USA shortly after release
<e2580>
we are restricted on the export due to US law :(
<e2580>
but it is pen source, so the device will be built by other :)
<panda|z>
e2580: so a lot of people in U.S need such device to protect their data on SD card? or just for some professional users?
<e2580>
this device is mostly for IT or security professionals. but anyone interested in true data security, or small businesses, or anyone doing R&D that needs secure data storage will be interested
<e2580>
the average person will likely not need this device
<e2580>
you dont need a bank vault at fort knox to protect $20 lol
<panda|z>
yeah, it's a too heavy gun
<e2580>
it will have some other functions for normal users
<e2580>
such as emulating a cdrom with iso, so you cn load iso on one of the sd cards, and it will act as cdrom
<e2580>
the other will be storage encrypted
<e2580>
firmware is upgradeable on the device, so you can make it do many other things
dandon has joined #qi-hardware
<whitequark>
e2580: so I need to enter the passkey via the buttons?..
<whitequark>
sounds quite tedious
<whitequark>
besides that, there were quite a few articles on circumventing hardware security
<whitequark>
simplest is to cover parts of the chip with UV-impenetrable substance and then use UV to erase the, for example, firmware, or fuse bits
<whitequark>
you can do very interesting things with an AFM, and you can get one with $10k if you want
<whitequark>
also, hardware AES bitstream crypto was broken on a certain military-grade FPGA by analyzing EM emissions
<whitequark>
statistically
<whitequark>
being open-source is nice, but I assume from the export restrictions that you use a specialized chip with a hardware crypto module, and it's pretty certainly not open-source
<whitequark>
I also don't see the partnumber of the chip anywhere on the website
<e2580>
whitequark, link me to any articles
<e2580>
DPA is not going to be possible on this device, it has ECM enabled
<e2580>
also, this device is not UV eeprom
<whitequark>
e2580: obviously it isn't UV eeprom
<whitequark>
but you can erase any eeprom with UV rays if you expose the die :)
<e2580>
also, the aes key is not stored on the device, so you wont be able to gain much from the mico even if you found a way to crack it (highly unlikely)
<whitequark>
where is it stored?
<whitequark>
or, rather, the salt part of the key
<whitequark>
I guess the AES key is derived from the user input. is that correct?
<kyak>
5 button means total of
<whitequark>
kyak: the key is entered with four buttons, and it has arbitrary length
<kyak>
oh ok)
<whitequark>
think entering 2-bit characters per click
<e2580>
user input key > salt, stored on the micro controller > hash = aes key. aes key is not stored. instead a data block is decrypted with the resulting aes key and checked for a value, if the value that is decrypted is correct, they the key is considered valid, else it is not valid
<whitequark>
which classes of attacks are you trying to prevent?
<e2580>
5 buttons, each is 2bit, so you can have 4-128 digit passwords. but since the user data is salted, it doesnt matter much (in theory) what the length of user input is
<whitequark>
it matters a lot
<e2580>
we are trying to defeat all kinds of attacks..
<whitequark>
because if your input is short, and you can extract the salt from within the microcontroller
<whitequark>
you can trivially brute-force the key
<whitequark>
all kinds of attacks? hah. what about the "connect standalone VBUS and just steal the device with the key in RAM" attack?
<e2580>
removing the data from the micro will not be as easy as this article describes.. i would like to see someone try it on this at32uc3a3256s.
<whitequark>
I would like to see an analysis of that attack channel, too.
<e2580>
however, i would suggest a long password just in case salt is some how obtained
<kyak>
btw, i just bought a soldering iron, literally half an hour ago :) it this is used for attack, it will be very hard to prevent :)
<e2580>
the key is only in the device memory when it is unlocked
<e2580>
and then, only in secure memory
<e2580>
there isnt a ram dump to get the key from memoryon the MCU
<whitequark>
e2580: that is correct. but I don't see any hardware countermeasures against selective erasing mentioned in the datasheet
<whitequark>
which means that no, the need to erase complete chip could be easily circumvented as it has been already shown
<whitequark>
it _is_ circumvented even when the EEPROMs are covered by metal areas, and here they're probably bare.
<e2580>
there are 6 user accessable gpio on the device, you can add your own solutions
<e2580>
the countermeasure for a UV attack like you suggested, if it is even possible for this micro is already used. only the salt is store. so the key is still missing
<e2580>
you need the user entered password, and the salt to generate the aes key for encryption/decryption
<whitequark>
yeah, I understand that
<whitequark>
which hash do you use?
<e2580>
so unless the data is in an unlocked state, the aes key is not in the device.. if the device is unlocked, why do all the work for a UV attack, just read the data
<whitequark>
unless it's a hard-to-compute hash function like PBKDF2, a, for example, 64-bit user input could be trivially bruteforced by an array of FPGAs
<e2580>
sha256 will likely be used for the default hash, we will offer many firmware versions, and users can ad their own code.
<whitequark>
I would suggest to use a hash function which isn't optimized for speed
<e2580>
we may chain several hash alg. to increase compute time
<whitequark>
there are well-known solutions for that problem already
<whitequark>
google 'bcrypt'
<whitequark>
the problem is, your microcontroller is severely underpowered. what takes a hour on it could be computed in a second on an fpga.
<e2580>
the key only needs to be calculated on unlocking, so a few seconds delay to user is not a big deal. yes, i know this is less time of fpga or gpu cluster etc.. but still adds computational cost to brute force
<whitequark>
exactly
<whitequark>
so you need to estimate the bruteforce times and give an advice on the size of user input
<panda|z>
e2580: it's pretty interesting, AES256 key is stored on this device, so users need to maintain it in the safe place physically such as safe box
<e2580>
we do have methods to prevent hardware attack on the MCU, which will be released on the forum later. the user can make use of the gpio to add protections. we will not add these optional methods, due to praticallity, leagality or other reasons. but it is possible to prevent any type of mcu attack
<e2580>
aes256 key is not stored on the device...
<panda|z>
e2580: crackers might anonymously install some daemon like USB monitor on host side to try to sniff the data?
<e2580>
the host side data is plain text
<e2580>
plain text goes into and comes out of the device, it is encrypted on the fly in the MCU and written encrypted to the sd cards
<e2580>
you can monitor the data lines on the usb all you want, its plain text, so why bother if you have that access ?
<panda|z>
e2580: oh, I see
<panda|z>
e2580: sorry, I'm still wondering the use case :)
<e2580>
the device is for securing data at rest
<e2580>
stored data
<panda|z>
e2580: OK, so howto generate, dispatch and maintain the aes256 key?
<e2580>
dispatch ?
<e2580>
user enter password > salt > hash = aes key. then check the aes key is correct by reading a block of encrypted data and check for expected value. if value is ok, then aes key is ok, if not, key is bad
<e2580>
aes key is stored while in use only, in secure ram of the mcu
<panda|z>
e2580: ah, I used to think all the aes256 key are under control from you guys, just in case, if end user lost their crypt2x, then you guys can help them issue a new one as replacement
<e2580>
haha
<e2580>
no
<e2580>
if the key is lost, or if you wipe the salt ie by too many bad passkey attempts the data is lost
<panda|z>
no? so if end user lost their crypt2x or it's physically been destoryed by force, there is no way to recovery any crypted data on SD card?
<e2580>
there is no recovery
<e2580>
unless you can break aes256 then no
<panda|z>
em ... it is really a secure device ...
<panda|z>
so what's the risk for you guys hold user's aes key as a truested 3rd party?
<e2580>
the device goal is security over ease of use... so no recovery functions
<panda|z>
users still hold their 5 key code, just like automobile manufacture for holding engine code
<e2580>
that adds unneeded risk to the security of the device, you cant validate our storage methods
jluis has joined #qi-hardware
<panda|z>
sorry, I'm totally a newbie with those naive questions, but trust me, I just ask cause those are not included in your current FAQ
<e2580>
do you trust us... companies like RSA and ssl cert issuers can be attacked, so why trust us ?
<e2580>
the goal of open source is to make the code openly available for review
<e2580>
if you give us the key, that means somewhere out there, there is a way to break your security
<panda|z>
e2580: but it's a two factor authentication, user still hold their 5 buttons password
<e2580>
ok, so you are asking if we can backup the salt ?
<panda|z>
oh, right, that's the point!
<e2580>
you can do some kinds of data back up
<e2580>
you can do a disk image of the sd cards. but you still need the cryptx2 to decrypt it, so you must use the same device, and user passkey
<panda|z>
e2580: oops, nono ...
<e2580>
or, you can unlock the cryptx2, and copy the files like you would on a normal hard drive and save them somepalce else
<panda|z>
e2580: what is the defination of 'salt', if user hold their password, they can re-generate the salt again?
<e2580>
salt is like a second part of the password
<e2580>
so to unlcok the device you need both, user entered passkey and the salt, to then make the aes key
<e2580>
the salt is stored in the MCU
<e2580>
randomly generated when you format the device
<e2580>
in the default firmware the salt is randomly generated, so you dont know what it is, and you cant restore it
<panda|z>
e2580: so user backup salt is possible and will be able to use the same password with salt to get the same aes256 key if they lost their crypt2x?
<e2580>
on alternate firmware we will allow users to create their own, so they can back it up then in case the cryptx2 needs to be replaced, they can gain access to the data on a new one
<e2580>
in the default firmware, you CANT backup the salt. that is part f the security
<kyak>
xiangfu: hi, just checking the latest minimal build.. i think you should keep the xorg.feed patches, otherwise it will fail all the time.
<e2580>
the salt is going to be more secure if it is randomly generated, VS user input which is much less likely to be high entropy
<panda|z>
e2580: well, I'm thinking of using this device in this way, plug one at home PC, another one at home, then bring SD cards with me everyday, so if I can clone with the same salt, then it's possible?
<panda|z>
sigh, maybe using crypt2x in this way will break some basic known security regulation:(
<e2580>
with the alernate firmware we will offer, you can do that. but not with the default firmware. you can change the firmware easily yourself
<panda|z>
e2580: cool, I see, thanks for your details, so how much for such a device?
<e2580>
target price is $65-75 USD with no sd cards
<panda|z>
e2580: wow! any possible to run it on kickstarter and make it much cheap with big volume?
<e2580>
we are doing kickstarter, within about 2 weeks
<e2580>
this is the kickstarter price
<panda|z>
e2580: cool! I will think about to back your project
<panda|z>
hopefully as a early bird:)
<e2580>
the website has an email notification list, we will send an advanced email to people on that list
urandom__ has joined #qi-hardware
<viric>
damn autotools
<xiangfu>
kyak, yes. applied. it will apply those 2 patch(xorg. and your openwrt.ticket12317.patch) to both minimal and full_system build.
<xiangfu>
kyak, let's see how emacs build.
<xiangfu>
thanks to David for fixing the emacs build error.
<viric>
damn podofo. I can't build it for mips32
<viric>
/tmp/nix-build-r9q21gmnzjd324c7ygldpj53afx5mmvi-podofo-0.9.1-mipsel-unknown-linux.drv-1/podofo-0.9.1/src/base/PdfCompilerCompatPrivate.h:148:37: error: invalid 'asm': invalid use of '%w'
<viric>
I think it has some "htons" in asm
<xiangfu>
viric, some head files problem? like gcc parameters -I etc. (I just do a quick google :)
e2580 has quit [Quit: Ex-Chat]
<viric>
no idea :)
<viric>
I've to dig.
dandon has quit [Quit: .]
xiangfu has quit [Ping timeout: 245 seconds]
heberth has joined #qi-hardware
urandom__ has quit [Quit: Konversation terminated!]
xiangfu has joined #qi-hardware
xiangfu has quit [Read error: Connection reset by peer]
porchaso0 has joined #qi-hardware
porchao has quit [Ping timeout: 240 seconds]
guanucoluis has joined #qi-hardware
antgreen has joined #qi-hardware
dandon has joined #qi-hardware
pcercuei has joined #qi-hardware
heberth has quit [Quit: Lost terminal]
heberth has joined #qi-hardware
antgreen has quit [Ping timeout: 245 seconds]
antgreen has joined #qi-hardware
heberth has quit [Quit: leaving]
viric_ has joined #qi-hardware
viric has quit [Ping timeout: 268 seconds]
LunaVorax has joined #qi-hardware
LunaVorax has quit [Ping timeout: 248 seconds]
jluis has quit [Ping timeout: 260 seconds]
emeb has joined #qi-hardware
jluis has joined #qi-hardware
LunaVorax has joined #qi-hardware
LunaVorax has quit [Ping timeout: 252 seconds]
GNUtoo-desktop has joined #qi-hardware
LunaVorax has joined #qi-hardware
lekernel_ has joined #qi-hardware
lekernel has quit [Read error: Operation timed out]
GNUtoo-desktop has quit [Quit: [INFO] fsogsmd : received signal -11, exiting.]
heberth has joined #qi-hardware
LunaVorax has quit [Remote host closed the connection]
antgreen has quit [Ping timeout: 245 seconds]
jekhor has joined #qi-hardware
jekhor has quit [Ping timeout: 265 seconds]
kristoffer has quit [Quit: Leaving]
urandom__ has joined #qi-hardware
jekhor has joined #qi-hardware
kristianpaul has quit [Ping timeout: 260 seconds]
heberth has quit [Quit: leaving]
kristianpaul has joined #qi-hardware
kristianpaul has quit [Changing host]
kristianpaul has joined #qi-hardware
dandon has quit [Quit: i'll be so back later. lol women in binders. a binder of women]