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> Cpu
<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 cpu
<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.cpp#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.cpp#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

26 KiB Raw Permalink Blame History

Logs

26 KiB

Raw Permalink Blame History