Logs for the Hardware Firmware Meeting Held on 2018-01-12
January 12, 2018
Logs
<i-a> Hello all, it is time for our firmware meeting to start. I am not sure if it is not too early to have a meeting like this, but let's see.
<i-a> Strange, there were so many people saying they have questions about code and now nobody is here:) So I will give a quick update on our project:
<i-a> Ok here is the quick update: USB communications is working, alse we can generate wallet by using internal random number generator (thanks god for m2049r, nice job)
<i-a> Maybe you have some recommendation how to move from here? My questions could look silly, but thats because I am personally just learning monero.
<m2049r[m]> :)
<i-a> On the other hand, there are other people working and maybe my questions could help also to them.
<m2049r[m]> is there anyone here who is actually taking part in this meeting besides us two?
<hotoatmeal> is the plan to use the same strategy that the ledger guy came up with, where private keys are sent (encrypted) from the device to the wallet?
<qqitty> CS noob looking to study xmr code this weekend. any design books/web guides to read like Huang's dissecting BTC?
<hotoatmeal> m2049r[m]: I'm mostly passively participating, until that question
<dEBRUYNE> m2049r[m]: Most people will probably just read until they want to say something :p
<i-a> hotoatmeal: We are here to speak about the plan.. I think if we want to do all the signing stuff in the device, we would need more memory.In case we need more memory, we will just setup a new device with bigger mcu.
<m2049r[m]> i would like an implementation where the keys never ever leave the device - we have to see if thats possible with the hardware constraints we have.
<hotoatmeal> I would like that too!
<i-a> It is still organic and you have perfect opportunity to bend the way how it is being developped:)
<i-a> Me too.
<m2049r[m]> there may be multiple implementations, with different roads to success.
<hotoatmeal> I don't yet understand how to find transaction outputs without revealing the view key
<m2049r[m]> without having studies the code i think it should be possible to hook into the code and have the device take over when keys are in play.
<hotoatmeal> if that's not possible, then the entire blockchain would have to be fed through the device over usb…. might be quite slow.
<m2049r[m]> (into the wallet client code)
<m2049r[m]> yes - but thats probably not a good idea - and were back to sending the keys to the client
<hotoatmeal> yeah :/
<hotoatmeal> too bad homeomorphic encryption systems are so slow
<hotoatmeal> otherwise you could trustlessly give the client an encrypted version of your view key, let it scan the blockchain for you, and provide the relevant txo's (also encrypted)
<hotoatmeal> and have the device decrypt the computed result
<m2049r[m]> i need to read up on how exactly the keys are used in the clients - any specific hint on where to get started?
<hotoatmeal> cryptonote paper is where I got started
<hotoatmeal> also looking at the ledger guy's patch
<m2049r[m]> i am not sure the communication to & from the device needs to be encrypted - are you worried about usb sniffers?
<jbdatko> hotoatmeal, can you link that patch?
<m2049r[m]> and if yes, whats the attack?
<hotoatmeal> so two separate things, both with different reasons for encryption
<qqitty2> Thanks @hotoatmeal. I'll go dive into the cryptonote WP
<m2049r[m]> cryptonote paper seems mostly vague
<hotoatmeal> ledger guy's patch encrypts the communication because it's transferring raw key data
<hotoatmeal> should be a no-brainer that that should be encrypted
<luigi1111> Paper is pretty clear unless you want implementation specifics
<m2049r[m]> heh yes
<hotoatmeal> this other thing about H-E, is a separate idea, and that's to allow someone else to scan the blockchain on your behalf, without revealing your view key to them (losing your privacy)
<m2049r[m]> paper is clear - i meant vague in the sense of implementation specifics
<m2049r[m]> H-E?
<luigi1111> I think you pretty much have to have client do the scanning
<luigi1111> Not the hw
<hotoatmeal> homeomorphic encryption
<dEBRUYNE> jbdatko: It's under open PRs on the monero repository
<luigi1111> Unless you have some hw acceleration it's just too slow
<i-a> luigi1111: yes but is there a way how to do it?
<luigi1111> How to do which
<hotoatmeal> i.e. someone else performs math on encrypted values that they can't see, and returns the result to you
<i-a> how to let PC scan the whole blockchain and prepare outgoing tx in a way, that the are sent to device just for signing.
<luigi1111> Sure
<luigi1111> The cold wallet signing basically does this already
<hotoatmeal> the problem is that H-E implementations of crypto algos are really really really slow
<hotoatmeal> like hours for a single round of AES
<luigi1111> That'd probably be slower than the device doing the scanning ^^
<luigi1111> :)
<hotoatmeal> yeah
<i-a> :(
<hotoatmeal> but in terms of mathematical purity / elegance… I really want that kind of solution to work :)
<hotoatmeal> jbdatko: https://github.com/monero-project/monero/pull/3095
<i-a> Ok, another question: If device did he whole scanning. How much memory we need on the device? I think that downlink from peers is usually slower than USB, so limitations is more in memory requirement at the device.
<m2049r[m]> how big of a problem would it be to reveal the viewkey to the client?
<luigi1111> Not memory
<luigi1111> *****u
<luigi1111> I don't think it's an issue
<luigi1111> I mean it isn't perfect
<luigi1111> But it has the benefit of being workable
<hotoatmeal> revealing to the client just means that you can't have a non-daemon client
<luigi1111> Sure you can
<i-a> yes but it is fine for now I think.
<luigi1111> You could have a remote node
<hotoatmeal> well, yeah
<luigi1111> All the way to mymonero
<m2049r[m]> the client wallet cache - is that encrypted?
<moneromooo> Yes.
<m2049r[m]> thought so - so the device would need to do that as well.
<hotoatmeal> is it possible to give the client an image of the view key, and then have it search the blockchain for some subset of txo's that /might/ match (as a coarse filter)?
<endogenic> vtnerd
<jbdatko> hotoatmeal, thank you
<hotoatmeal> (reducing the amount of work the device has to do, but not giving up the full key data?)
<m2049r[m]> how would that work?
<jbdatko> AES accelerators on MCU are pretty good now, so depending on the MCU it might not be completely horrible (sorry I'm jumping in w/o knowing the full context)
<endogenic> hotoatmeal: mrl has been workin on this problem for some time
<hotoatmeal> endogenic: anything I'm saying known not to be worth pursuing? (by proofs that it doesn't work, or somesuch)
<m2049r[m]> we have space for secure elements on the board - things which can do aes and other things in hardware.
<luigi1111w> you need ed25519 acceleration
<luigi1111w> which I doubt exists
<m2049r[m]> yeah, except that.
<hotoatmeal> heh. now it needs an fpga
<luigi1111w> I don't really see any way around it
<luigi1111w> mymonero as a hw client would actually be quite desirable
<luigi1111w> and quite an upgrade
<luigi1111w> well it all depends on perspective :)
<endogenic> :)
<luigi1111w> the most secure/private arrangement would be user owned daemon -> wallet/client -> hw
<luigi1111w> but you can delegate the first two for privacy loss
<luigi1111w> well the first one isn't really privacy loss
<i-a> our nordic semiconductor candidate has ed25519 hw block, but we still didnt get them.
<luigi1111w> or a different type or of privacy
<luigi1111w> i-a that's interesting
<luigi1111w> I'd be curious to see perf numbers
<m2049r[m]> i-a but thats with an nda so we cant be open source, no?
<luigi1111w> for some usable ed25519 operation
<i-a> luigi1111w: nRF52840, it has secure crypto cell or something like that.
<i-a> Of course there are other problems, like a non open design and so on.
<msvb-mob> cryptocell is available without nda.
<luigi1111w> I mean something like signatures/sec
<i-a> another question is if this cryptocell ed25519 is fast enough to be usable.
<luigi1111w> that was my only question :)
<i-a> Unfortunately I dont know now. But I will try to find out. It seems like as-fast-as-possibe ed25529 od device is a must.
<hotoatmeal> do you have a ballpark for how fast it would have to be to be usable?
<msvb-mob> cec1702 has the cuve too.
<i-a> msvb-mob: nice, can we somehow determine their performance?
<m2049r[m]> they sortof claim its 10x a software solution but dont show numbers
<luigi1111w> software solution on that power of hw?
<luigi1111w> IDK, something similar to an older *****u
<msvb-mob> i-a: I don't know how to measure performance without testing the devices on real hardware, unfortunately.
<i-a> https://www.microchip.com/wwwproducts/en/CEC1702
<i-a> this is it \^
<m2049r[m]> thats the question luigi - its blabla
<m2049r[m]> can we GET real hardware?
<luigi1111w> :)
<i-a> msvb-mob: hmm:( are we going to have cec1702 to do some testing?
<luigi1111w> I think it would be really cool if such a device could be made
<luigi1111w> but I'm skeptical
<msvb-mob> m2049r[m]: I can send you a nRF52840-DK if you want.
<luigi1111w> we know the viewkey delegation works, at least
<msvb-mob> i-a: The nRF is easy (there's a devkit for that) but to test the CEC1702 we must make the boards ourselves first.
<luigi1111w> (mymonero and openmonero both use the exact same idea already)
<msvb-mob> I think the MCUs are already in my lab.
<i-a> msvb-mob: that is not a big deal, if you know the are comming, i can send you a board asap.
<i-a> (lets say gerbers on monday/tuesday)
<i-a> msvb-mob: what about nda on this cec1702? Or do they have some problem?
<msvb-mob> The CEC1702 is not NDA encumbered.
<i-a> perfect candidate -_-
<msvb-mob> Yes, I think so too.
<m2049r[m]> the CEC1702 & the nRF52840 would replace our MCU?
<i-a> m2049r[m]: I think yes, because our mcu is lacking ed25519
<msvb-mob> m2049r[m]: They are both Cortex-M4 MCUs so they could do so. If they aren't large enough to contain transactions in memory or code in program storage we could use them as coprocessors probably.
<msvb-mob> Would be a bit weird.
<m2049r[m]> we have to see what they mean by ed25519. do we need just signing & verifying or do we also need curve arithmetic luigi1111w
<luigi1111w> signing and verifying sorta-mostly-ish include all the operations needed
<luigi1111w> I guess that's not really true
<luigi1111w> but the operations that need accelerated would be, mostly
<m2049r[m]> the data sheets says:
<m2049r[m]> Elliptic Curve point multiply with Curve25519
<m2049r[m]> The Edwards-curve Digital Signature Algorithm (EdDSA), using Curve25519
<m2049r[m]> (CEC1702)
<iDunk> ed25519 != Curve25519.
<i-a> nRF does both i think
<i-a> yes
<i-a> but cec1702 doesn't have ed25519:( or I cannot find it in datasheet.
<m2049r[m]> the nrf can create keys, sign & verify. "The generation is performed using EC Edwards ed25519 algorithm."
<i-a> cec1702 has only Curve25519
<luigi1111w> if they are going off of nacl or similar they have both
<luigi1111w> the signing is ed
<luigi1111w> and the box stuff is curve255
<msvb-mob> i-a: No ECDSA on CEC1702? I don't have the documents with me now.
<i-a> ok so to be clear:
<i-a> The Elliptic Curve Digital Signature Algorit
<i-a> hm (ECDSA), using all supported NIST curves
<i-a> he Edwards-curve Digital Signatur
<i-a> e Algorithm (EdDSA), using Curve25519
<luigi1111w> that could be naming issues though :)
<i-a> maybe ed25519 is hidden somewhere, but it isn explicitly mentioned, Curve25519 is mentioned.
<i-a> *isnt
<luigi1111w> yeah they are often bundled together
<m2049r[m]> so you are saying we need new hardware in any case?
<luigi1111w> to attempt to "do everyone on device", yes (and I'm doubtful it's possible)
<luigi1111w> to do a client-delegated arrangement, no
<hotoatmeal> these slides say they can do ~1400 ECDH's /s on a cortex A8: https://cr.yp.to/talks/2012.11.29/slides.pdf
<msvb-mob> i-a: The ED25519 API is on pages 60-61 of the CEC/MEC Family Devices ROM API Users Guide.
<i-a> msvb-mob: thank you,)
<msvb-mob> For example ed25519_valid_sig (validate signature) is a function.
<hotoatmeal> and Ed25519 was only a bit slower
<hotoatmeal> what's the rough size of the blockchain, counted in txo's?
<luigi1111w> total size isn't that useful
<luigi1111w> size over past month much more so
<hotoatmeal> growth rate too
<luigi1111w> yeah with some assumed groth
<luigi1111w> growth
<luigi1111w> 200k txs last month
<luigi1111w> so maybe 450k outputs
<luigi1111w> double that at least gets you 1mi/mo
<luigi1111w> checking an output is something like 2x ECDH
<hotoatmeal> so it'll get slower by 20 mins, every month
<hotoatmeal> ouch
<luigi1111w> if you don't use it
<luigi1111w> but yeah
<hotoatmeal> (assuming you need to re-scan the entire chain each time… but maybe that can be cached)
<luigi1111w> there would be quite some catchup time
<i-a> not sure if relevant, but this could be ECDSA performance on CEC device: https://imgur.com/a/WQKqp ?
<luigi1111w> if you leave it unplugged for some time
<luigi1111w> oh
<luigi1111w> I would sure assume you cache
<luigi1111w> if you don't it
<luigi1111w> it's pretty unworkable
<hotoatmeal> yeah
<luigi1111w> you'd have to leave it plugged in a few hours before you could spend each time :)
<hotoatmeal> the worst case of initializing a new device though is pretty bad
<hotoatmeal> though I guess you could just sweep everything to it, and ignore all of the chain that happened before then
<luigi1111w> restored device
<luigi1111w> new device has no txs
<hotoatmeal> right
<hotoatmeal> at least the restore point is something you can make note of, encrypt, and then store like any other backup
<m2049r[m]> are you suggesting we keep the chain/cache on the device?
<luigi1111w> no
<luigi1111w> definitely not the chain
<luigi1111w> I'm still skeptical it's workable at all, just exploring the idea
<m2049r[m]> gottit
<hotoatmeal> do bulletproofs change the costs here?
<hotoatmeal> s.do.will.
<m2049r[m]> do we have constraints about how big the device may be?
<endogenic> yes
<luigi1111w> hotoatmeal no
<endogenic> :P
<luigi1111w> m2049r[m] just tote a computer around
<luigi1111w> NP
<luigi1111w> "this is my hardware wallet"
<m2049r[m]> what if we use a rpi3 to do all the work & store the caches for all the wallets onboard?
<m2049r[m]> :)
<endogenic> now we're cookin with gas
<luigi1111w> it's pretty slow too
<luigi1111w> normal client scanning on computer seems pretty ok to me
<m2049r[m]> how fast does it need to be? do we want full USB3 speeds?
<luigi1111w> by compromising your computer, the hacker now compromises just your privacy
<luigi1111w> rather than
<luigi1111w> you know
<luigi1111w> all your money
<i-a> you can run node on rp3, so it probably isnt so slow..?
<hotoatmeal> m2049r[m]: delegating the viewkey to the computer means it doesn't have to be very quick at all
<luigi1111w> i-a how long does initial sync take
<hotoatmeal> (the device / usb, that is)
<luigi1111w> how long would it take to scan a restored wallet
<m2049r[m]> that would have been the first path to explore
<i-a> luigi1111w: ok, got it:/
<endogenic> i-a no no that's just bc node is fast… because it's asynchronous (now it's my turn to troll)
<luigi1111w> is an rpi significantly better than a normal computer?
<luigi1111w> m2049r[m] if you slim the data down to close to minimum I don't think bandwidth is much concern
<luigi1111w> lemme see
<m2049r[m]> so bottleneck is always computation then. and we want it fast so we dont take forever to sync up again.
<luigi1111w> I'd guess around 240 bytes per tx
<m2049r[m]> if we keep cache on device (sdcard or whatnot) then it can be shared between clients.
<luigi1111w> so even .25MBps would overwhelm the device most likely
<m2049r[m]> 240 either way?
<luigi1111w> no just computer->device
**<hotoatmeal> another idea: put the viewkey on a separate device that's always connected to a computer
<msvb-mob> There have been some requests for SD cards, so it would be nice to try to put one on at least the developer edition board (since it has more space.)
<m2049r[m]> yes - use a viewonly wallet.
<msvb-mob> m2049r[m]: Shift devices makes quite a nice hardware wallet (Bitbox) with a SD card.
<endogenic> do you guys suppose there's any reason why this isn't a match for the mymonero lightwallet server you run alongside the daemon?
<luigi1111w> I don't
<endogenic> i might be misunderstanding
<luigi1111w> I think it's great
<luigi1111w> it's also great for existing mymonero users (privacy issues notwithstanding, of course)
<luigi1111w> but I guess we're discussing the edge of what's possible
<luigi1111w> for having a device that does basically no delegation for maximal security and privacy in all cases
<m2049r[m]> you are saying to have the device connect to an openmonero instance?
<luigi1111w> or maybe just rainbows and unicorns
<endogenic> m2049r[m]: no
<endogenic> i was envisioning some sort of stripped down protocol…vtnerd and i are working on that anyway in the api overhaul
<m2049r[m]> ok, what are you saying?
<luigi1111w> he's talking about mymonero not openmonero
<endogenic> so if you're running your own local server
<luigi1111w> though in theory they are similar
<endogenic> which is written in C++ and in the monero-cli repo alongside the official daemon
<endogenic> it almost seems like it's more a question of protocol and transport
<endogenic> that is
<endogenic> if we really are talking about delegating scanning
<endogenic> of course you have the view key disclosure tradeoff but that's why you run your own server locally
<m2049r[m]> i thought mymonero was closed source and not for anyone to run their own?
<luigi1111w> it is
<luigi1111w> but it won't be for much longer
<luigi1111w> supposedly :)
<endogenic> yep
<endogenic> vtnerd's prioritized it recently
<m2049r[m]> heh
<endogenic> he hadnt been able to before
<endogenic> too many pesky users!
<endogenic> but anyway
<endogenic> this idea does seem to overlap with simplewallet/monero-gui's job too
<luigi1111w> the theory of mymonero locally vs gui/cli is pretty similar
<luigi1111w> yes
<endogenic> does that count as a jinx?
<luigi1111w> slow motion
<endogenic> mm
<endogenic> anyway, whatever software we need, we can build
<endogenic> might be a good idea to just ask what the ideal situation is for the capabilities we have on the hardware side then fill the gaps
<m2049r[m]> we agree that we need lots of well-performing ed25519 operations on the device - no matter which road is taken?
<m2049r[m]> and possibly some form of storage (sdcard,eMMC?)
<luigi1111w> m2049r[m] more is better
<luigi1111w> but it doesn't need to be "a lot" for the delegated road
<luigi1111w> which includes basically everything that's not "do it all on device"
<luigi1111w> whether local client or some mymonero type
<m2049r[m]> signing would be on device for example - how large are the messages to be signed / verified?
<luigi1111w> it does need to be able to hash some KBs yes
<luigi1111w> 50 max, maybe
<luigi1111w> theoretically more, but shouldn't really happen anymore, in most cases
<m2049r[m]> the cec1702 has 24k of "cryptographic ram" which seems to be the ram where cryptomagic happens.
<m2049r[m]> "in most cases" - one case is enough to break it though - so for such cases we would need a software solution to kick in and have the hardware do 99% of cases.
<m2049r[m]> (this is not a problem)
<m2049r[m]> do you have a particular testcase i could run just to see how slow the current device is performing?
<luigi1111w> no I mean you can just disallow
<luigi1111w> would need some research to really know how annoying that would be though
<luigi1111w> (problem comes from having many inputs)
<luigi1111w> ((I guess mining to the wallet could cause it))
<luigi1111w> m2049r[m] well if you have ed25519 code working on it
<m2049r[m]> i do
<luigi1111w> a simple scalarmult
<m2049r[m]> regardless of parameters?
<luigi1111w> random secret key
<luigi1111w> public key needs to be valid at least
<luigi1111w> or a simple scalarmult_base if you have that
<m2049r[m]> including convesion from/to 256-bit scalars or the mult by itself?
<luigi1111w> including
<cslashm> m2049r[m]: hotoatmeal: Yes All secret value are passed encrypted from device to PC. When PC need perform operation with those values, there are retransmitted to the device
<luigi1111w> https://github.com/monero-project/monero/blob/master/src/crypto/crypto.*****p#L127
<luigi1111w> if you can match that
<m2049r[m]> ok - like the operation need to make a public key out of a secret key (eg. viewkey)?
<luigi1111w> yes
<luigi1111w> that includes a conversion from fe to bytes at the end
<m2049r[m]> i can do that. need to add time measuring stuff.
<m2049r[m]> will do that tomorrow and get back with results.
<luigi1111w> cool
<luigi1111w> might as well do arbitrary base too if it's not much more work
<luigi1111w> https://github.com/monero-project/monero/blob/master/src/crypto/crypto.*****p#L127
<luigi1111w> you can use any valid point for the pubkey param
<luigi1111w> I can give you one in hex if you want
<luigi1111w> or you can just gen one from the above function
<m2049r[m]> will pm you for more details
<m2049r[m]> cslashm: what encryption is used for the transmission of the keys over usb?
<cslashm> It will be AES128
<cslashm> the key will new at each app usage and dedicated to session when transfer is performed
<cslashm> But I try to send even encrypted the view and spend key
<cslashm> not send
<m2049r[m]> and the key exchange is DH?
<cslashm> which DH? The AES key never leave the device
<m2049r[m]> maybe i dont understand aes. isnt that symmetric? how does the pc decode the ciphertext?
<cslashm> PC never decode, I try to explain
<luigi1111w> he's using the pc for encrypted cache only it sounds like
<luigi1111w> but I don't think you need to send spend key ever
<luigi1111w> device has enough memory for that, surely
<cslashm> voila. PC is just a encrypted holder
<cslashm> The advantage is that it keep the secret at the right place
<m2049r[m]> a storage.
<cslashm> for exemple in RCT, it request n secret key, store in the right vector place, and when it use it, it resend the encrypted secret key to device, which decrypt and do the op
<cslashm> @luigi1111w: yes spend/view key never leave the device
<cslashm> I use special value 00..00 and FF…FF for them on PC side
<m2049r[m]> ok, gotta go - it's been great :)
<cslashm> basic idea is to hav no memory restriction, on easly follow the PC code evolution with minimal code device modification
<cslashm> and easly (end of day in FR :) )
<dEBRUYNE> cslashm: I've been wondering. Did you run any performance tests? For example, how long does it take to scan / refresh 10k blocks?
<cslashm> for now it's a OMG part
<cslashm> I start some perf test yes but didnot remenber
<dEBRUYNE> Approximately? :p
<cslashm> It is just impossible to rescan the whole blockchain
<cslashm> holdon, deep search in paper on my desk
<dEBRUYNE> Yeah, but that won't be necessary for 99% of the users :P
<cslashm> 10 min for 20 000 block, but app in -0O and level 4 log
<cslashm> wallet cli also in O0
<dEBRUYNE> I see, that doesn't seem too bad tbh
<luigi1111w> that is scanning by cli, not ledger, right?
<cslashm> Its acceptable if you dont move in vacation for 1 month without refresh :D
<cslashm> no wallet cli scan the bc but delegate all keyderivation/keyimage computation to ledger to no disclose the view key
<dEBRUYNE> well, 1 month is 22k blocks give or take
<cslashm> So for each block, device compute some scalmul and hash
<dEBRUYNE> So that'd be 10 minutes wait
<luigi1111w> you can't really use blocks
<luigi1111w> you have to use txs
<luigi1111w> are those current numbers
<luigi1111w> what will it look like if usage goes up (which it historically has)
<luigi1111w> I personally don't really see a lot of benefit for disclosing the viewkey
<cslashm> yes for each txes. basically scan involves get_key_derivation and generate_key_image, those two op are done by the device. The rest is done by the PC as usual
<cslashm> view key is so never disclose
<cslashm> So, I need to leave. Be back on monday. you can mail, PM reddit or put githib issue if you need long tech desc
Post tags : Dev Diaries, Cryptography