monero-project/monero-site
monero-project/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2025-01-10 21:05:04 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge pull request #553 from dEBRUYNE-1/master

Browse source 
Logs for the Hardware meeting held on 2018-01-05 & the Hardware firmware meeting held on 2018-01-12
This commit is contained in:
luigi1111 2018-01-19 04:53:32 -05:00 committed by GitHub
commit 9a5bb5e74b
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 768 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

382
_posts/2018-01-05-logs-for-the-Hardware-meeting-held-on-2018-01-05.md Normal file
View file

@ -0,0 +1,382 @@
---
layout: post
title: Logs for the Hardware Meeting Held on 2018-01-05
summary: Poll conducted, Reddit summaries, status report(s), conclusion of name search, highlights of 34C3 in Leipzig, etherpads for groups, test plan discussion, recent firmware & FPGA research, mechanical engineering, recent logo contributions, and miscellaneous
tags: [community, crypto]
author: dEBRUYNE / fluffypony
---
# Logs
**\<rehrar>** Hellooooo hardware peeps!
**\<luigi1111w>** I thought next friday
**\<msvb-lab>** luigi1111w: Yes, right now for an hour.
**\<luigi1111w>** ok
**\<nioc>** today and next Fri for software
**\<msvb-lab>** General hw team meeting, but Friday may or may not (to be decided) be s focus seesion on firmware.
**\<rehrar>** So we got a lot of ground to cover today, so let's hop into it.
**\<msvb-lab>** https://taiga.getmonero.org/project/michael-rfc-hwallet-1-implementation/wiki/meet/
**\<msvb-lab>** Is the agenda.
**\<rehrar>** So from my understanding, because we'll be moving quite quickly, we'll have to not spend tons of time on discussion per topic
**\<rehrar>** We can either talk after the meeting (if we want to continue conversation)
**\<msvb-lab>** rehrar: Yes, that's right. In fact, #1 is already done.
**\<rehrar>** or perhaps utilize another channel to have side conversations about stuff
**\<msvb-lab>** And #2 is cancelled.
**\<msvb-lab>** At the 30 minute mark we break into subgroups, that will be clear as we get to the point.
**\<rehrar>** Well then, we're already scurrying along.
**\<rehrar>** The third item on the agenda is the poll that is conducted?
**\<i-a>** hello!
**\<rehrar>** Are we talking about how it was conducted, or...? :)
**\<msvb-lab>** Just that the poll is always conducted on doodle and we have a choice when to hold meetings.
**\<msvb-lab>** This one there are at least three that can't make it due to time zone differences, too bad.
**\<i-a>** luigi1111w: today its more about logo, enclosure and a lot of different stuff. Meeting about firmware is lanned to be next friday.
**\<rehrar>** That's sad, indeed. Is there nothing that can be done?
**\<i-a>** \*planned
**\<luigi1111w>** ahh, ok
**\<rehrar>** Maybe a terrible idea, but what if two meetings were held covering the same agenda?
**\<msvb-lab>** We can try to build friendships with those folks in other timezones and keep them informed.
**\<luigi1111w>** I will just watch then
**\<rehrar>** One that is good for one set of timezones, and then next 12 hours later
**\<rehrar>** Alright, either way, we can discuss that later. Moving on!
**\<kamminke>** So, which item on the long agenda we discuss now first?
**\<rehrar>** we're at 4. Reddit summaries
**\<rehrar>** I was asked to go ahead and look through the Reddit threads that talk about Hardware
**\<rehrar>** the provided links are just two examples, although they are some of the bigger ones
**\<rehrar>** to give a brief summary: there is still a lot of people not understanding that the end result of this hardware project will not necessarily be this workgroup selling hardware wallets
**\<rehrar>** Perhaps we can discuss at a later time whether (once firmware is complete) this workgroup would like to take on the task of making (funded via FFS of course) a number of hardware wallets for the community
**\<m2049r[m]>** what are they understanding?
**\<rehrar>** They're asking about pre-orders, how to order, etc.
**\<rehrar>** They understand that at the end of this project will, the end result is a deliverable hardware wallet product
**\<sebgus>** rehrar: Sounds like a good idea. I could assist in this task (hardware assembly).
**\<dEBRUYNE>** There's a huge business opportunity though if you can actually deliver them for a decent price
**\<sebgus>** But maybe we want something on a more mass-produced scale, msvb?
**\<rehrar>** second thing I gleaned: tons of people want hardware wallet support yesterday. Comes as no surprise, but yeah. Thought I'd throw that in there.
**\<rehrar>** Thirdly: People are very supportive and impressed with the progress and work of this workgroup
**\<rehrar>** so congratulations are in order there
**\<rehrar>** and lastly: the obvious comparisons that occur between the goals of this workgroup and ledger/trezor come up very very often
**\<rehrar>** By reading the Reddit threads, this is the general pulse of how the community is viewing hardware development and this workgroup
**\<anhdres>** I suppose we'll need to have as good as a mertic of how many wallets could be sold before thinking about mass producing
**\<cslashm>** is there any sheet comparison of HW wallets projects?
**\<kamminke>** And, IMHO we have to become more secure as competitors.
**\<m2049r[m]>** (that & having a product which does something)
**\<rehrar>** it's hard to gauge without getting preorders, which would require an ahead-of-time commitment to such a thing from a group or individual
**\<rehrar>** It also does NOT have to be the job of this workgroup to produce and ship them
**\<rehrar>** there can be another workgroup tasked with that
**\<anhdres>** rehrar, yeah, a la kickstarter
**\<i-a>** (please dont think too much about selling stuff which doesnt exist yet)
**\<rehrar>** leaving this workgroup to continue to innovate and push forward in the hardware field
**\<rehrar>** \^ a great point
**\<anhdres>** agree
**\<serhack>** +1
**\<rehrar>** let's finish the tasks at hand first, then further discussions could commence
**\<msvb-lab>** Sorry.
**\<rehrar>** moving on
**\<rehrar>** 5. Status reports
**\<dEBRUYNE>** cslashm: There's Trezor, this group, and Ledger (you). Or didn't you mean it like that?
**\<rehrar>** first up, board additions
**\<msvb-lab>** We're still on track with two main editions.
**\<msvb-lab>** A developer (D) edition, larger and more complex good for devs.
**\<msvb-lab>** A consumer (C) edition, with excellent aesthetics and easy to use.
**\<rehrar>** we can continue conversations on previous points in #monero-hardware-aside. It'll just be used temporarily for this meeting
**\<msvb-lab>** Secure too, ahem.
**\<cslashm>** dEBRUYNE: juste ask if what the differenciator of each project is written down
**\<msvb-lab>** Is that okay with everyone else?
**\<eruheran>** dEBRUYNE, cslashm there is also KeepKey
**\<rehrar>** (I urge cslashm and dEBRUYNE to continue there :) )
**\<msvb-lab>** And Digital Bitbox, my favourite.
**\<msvb-lab>** The dividend results were namely that if folks were willing to give a mailing address, they got a play toy for the holiday season.
**\<sebgus>** msvb: Sounds reasonable with two versions.
**\<sebgus>** editions\*
**\<msvb-lab>** Regarding secure elements, we've had a mix of failure and success with diverse vendors.
**\<msvb-lab>** Most promising right now is ATECC608A, CEC1702, and nRF42850.
**\<msvb-lab>** Gemalto and ST Micro are more or less out, and most other vendors have no offering.
**\<msvb-lab>** Zylinkx sells a FPGA for 120 EUR.
**\<msvb-lab>** Any questions about secure elements, enclaves, or hardware security modules?
**\<tat>** hello i am a bit late to the meeting, my name is Morris and i meet Michael on the 34C3,
**\<msvb-lab>** tat: Super that you made it, thanks for tuning in.
**\<msvb-lab>** anhdres: Would you please announce our new repository/project name?
**\<tat>** I have read up during the last days on ledger history and i have a idea about a secure element that would work without NDA and is very cheap to come by.
**\<m2049r[m]>** yes - i doubt the need for a secure element
**\<jbdatko>** Hi, I'm Josh, new to this group. I've worked with the ATECC series a lot and recently the Xilinx zynq so I can answer questions on those secure element options if y'all have any
**\<m2049r[m]>** unless mabye it does curve25519 in hardware
**\<anhdres>** msvb-lab, sure?
**\<anhdres>** nah, you do it
**\<msvb-lab>** jbdatko: So this is quite an honour. Josh is the creator (almost 100%) of our Breakneck board, the developer edition.
**\<msvb-lab>** jbdatko: Welcome.
**\<i-a>** jbdatko: hello, nice to see you here!
**\* jbdatko** waves
**\<kamminke>** Still the same questions - does the secure elements support the right curve for signing?
**\<msvb-lab>** anhdres: Okay you nerd. I'll tell the world about our new mistake, the name for our sekura rejected repository is...
**\<msvb-lab>** kamminke: Yes, they have the curves ed25519.
**\<msvb-lab>** ...drummrolllll.
**\<rehrar>** YAY, what a name!
**\<rehrar>** oh
**\<msvb-lab>** The name is drumroll.
**\<rehrar>** I thought: kamminke: Yes, they have the curves ed25519. was it
**\<i-a>** m2049r[m]: I am also skeptical about secure elements, but if we make hw wallet secure by design, we can still enhance it by adding a storage for keys (and store them encrypted there)
**\* sarang** locates a drum
**\<msvb-lab>** KASTRATELO!
**\<msvb-lab>** Just joking. It's Katelo.
**\<i-a>** :D
**\<anhdres>** jaja
**\<rehrar>** Kastelo :P
**\<anhdres>** Kastelo
**\<msvb-lab>** Crap, I mean Kastelo. rehrar yes.
**\<rehrar>** this is why you don't let msvb-lab announce these things
**\<msvb-lab>** Well that went over quite clearly.
**\<tat>** My idea was a programmable smartcard that is embedded as a simcard within the wallet
**\<m2049r[m]>** we can use any eeprom for that
**\<serhack>** Kastratelo is a bad word in italy
**\<rehrar>** Ok. Epic! luigi1111 and luigi1111w we would be thrilled if some changes to the Sekura repo could be made
**\<cslashm>** About SE, you should consider the scope of HW and side channel attack. SE help for that
**\<tat>** they are very secure, nxp states they use more then 4000 anty tempering technics in there curent generation of java smartcards
**\<kamminke>** do you trust smartcards?
**\<luigi1111w>** aren't we the same person
**\<msvb-lab>** luigi1111w, yes you and the other luigi are the same person. Look in the mirror.
**\<sarang>** I always figured luigi1111 was some kind of secret society
**\<rehrar>** https://github.com/monero-project/meta/issues/136 is a good starting point
**\<i-a>** The wallet must be secure by design, please lets use secure elements only to enhance allready secure design.
**\<rehrar>** with the addition of changing the repo name to "Kastelo"
**\<rehrar>** alright, moving on.
**\<rehrar>** Again, conversation from older points can continue in #monero-hardware-aside
**\<rehrar>** 7. Highlights of 34C3 in Leipzig
**\<m2049r[m]>** an attack is only possible if you can make the device use your key - if you can do that ONCE, then you transfer the funds away and dont care about the key. no?
**\<msvb-lab>** i-a: Good point. jbdatko Josh do you believe that we can make a hardware wallet that's secure by design in that even when running a roque firmware the secrets remain safe?
**\<msvb-lab>** Ups, Josh not der.
**\<msvb-lab>** Okay, who wants to give a 34C3 summary?
**\<kamminke>** all algorithmen on CPUs you can easy attack with power analysis
**\<jbdatko>** hmm, the ultimate question yes? ;) Secure elements (try) to keep the private key from leaking but unfortunately with rogue firmware you also have to worry about somebody using the key. Rephrased: you don't have to leak the key to lose money you just have leak control of the key
**\<msvb-lab>** jbdatko: Interesting, and that's quite clear. So not the holy grail, yet possibly an instrument to use in securing.
**\<jbdatko>** But combing user input with a KDF passhprase that unlocks the SE I think is the design pattern
**\<cslashm>** Power Analysis is your enemi
**\<i-a>** It is a tradeof, (1) having secure elements which could be accessible only through a binary blob uploaded in flash, or having code which could possibly be attacked by side channel. I am not sure how to handle this.
**\<msvb-lab>** Does anyone want to give a summary about 34C3 in Leipzig?
**\<tat>** jbdatko: make the user confirm every transaction in an way that can not be tempered with
**\<cslashm>** I worked on cerfified product (ID)
**\<msvb-lab>** rehrar: Let's skip 34C3, as I think most people don't know what it is.
**\<rehrar>** sounds good
**\<msvb-lab>** Really not that big a deal probably.
**\<rehrar>** Well, next is Etherpads for the group
**\<msvb-lab>** Yes, we're at #8 and half way through.
**\<rehrar>** https://taiga.getmonero.org/project/michael-rfc-hwallet-1-implementation/wiki/meet
**\<rehrar>** this is the agenda for the meeting if you missed it
**\<anhdres>** I wish they released the videos from 34c3
**\<anhdres>** they're taking ages
**\<rehrar>** if you scroll down to item 8, you will see the different Etherpads set up for this group
**\<msvb-lab>** Each of us now takes a moment and if we wish, we can devote part of the next half hour (like an extra open browser window) to one of the subgroups.
**\<i-a>** 34c3 was incredibly good event, I have met many interesting people, I have given some boards and I am waiting for contributions! msvb-lab did a nice talk about hw wallet, also there was nice talk about monerujo android wallet, both should be online in a month.
**\<rehrar>** They're topic specific, and just another way to communicate, talk, and exchange ideas
**\<msvb-lab>** See the part after #8 Main project, QA test, Firmware...?
**\<rehrar>** Choose your Etherpad, and start disucssion?
**\<msvb-lab>** I'm going to click on Mechanics since I did meet more than a few interested in mechanical engineering.
**\<msvb-lab>** rehrar: We continue here in parallel with Test plan I think. Do you think it will work?
**\<rehrar>** *shrug* never tried it, but should be fun
**\<msvb-lab>** In the right hand side chat of the etherpads, if you want to be named, click the top most 'people' button and add your name there.
**\<i-a>** haha, how to make the crowd to disappear? show them etherpads:))
**\<m2049r[m]>** what is the exact attack vector we are addressing with a secure element?
**\<msvb-lab>** i-a: Yes, it seems this idea is either very good or very bad. No idea.
**\<m2049r[m]>** i-a: btw. i did all you said - its still broken
**\<msvb-lab>** Control over secrets is the attack vector.
**\<m2049r[m]>** thats too vague for me. how?
**\<i-a>** m2049r[m]: trying to PM you but i cannot, please could you try to pm me?
**\<m2049r[m]>** someone has to have phsyical access to the device. then what?
**\<msvb-lab>** m2049r[m]: Decapsulation is what I would attempt, it depends on many things.
**\<i-a>** m2049r[m]: "You must log in with services to message this user"
**\<kamminke>** We have to avoid, that someone, even with physical access to the hardware wallet, gets the key pair to sign transactions.
**\<msvb-lab>** i-a: That usually means you haven't set up a password with chat.freenode.net.
**\<rehrar>** i-a maybe you can try on the mattermost guys?
**\<msvb-lab>** kamminke: That's right, according to Josh it's not enough to fool all attackers all the time, but it's certainly a goal for us to block access to stealing the actual secret away from silicon.
**\<m2049r[m]>** decapsulation will not help you if the key is password-encoded
**\<msvb-lab>** Seems mechanical engineers and quality assurance folks are not the chatting types?
**\<msvb-lab>** Those etherpads are blowing crickets.
**\<m2049r[m]>** i-a: come to mattermost
**\<i-a>** m2049r[m]: I never did it, i am trying it now.
**\<sarang>** How would the key be encrypted?
**\<msvb-lab>** sarang: Symetric cypher.
**\<msvb-lab>** I'm not sure if that's how other wallets do it, but that's how SSH does for example.
**\<msvb-lab>** Wallets alway have these nasty mnemonic thingies, so that throws a curve.
**\<msvb-lab>** But encrypting a key is no problem. Not that I agree it allows us to avoid a secure element.
**\<jbdatko>** When in doubt, use libsodium (NaCl) based stuff -- there is a KDF and a PKDF function there that could be ported to bare-metal C (I think it's close already just some linux-y calls)
**\<msvb-lab>** By that theory we could use a magnetic hard drive and be safe enough.
**\<sarang>** If you want to avoid someone lifting the encrypted blob and hammering away at it, a simple symmetric cipher without a KDF would be very bad
**\<sarang>** jbdatko: yes, a KDF is essential
**\<msvb-lab>** jbdatko: To encrypt a ed25519 secret, we could use a ATECC608A because it has PKDF right?
**\<jbdatko>** so the 608A does have HKDF so you could use it to create a key tree of sorts
**\<msvb-lab>** sarang: It's golden when monero-hardware is teaming MRL folks a lesson. Har har har.
**\<sarang>** PBKDF2 is useful for low-memory settings
**\<sarang>** ?
**\<jbdatko>** The biggest issue I would think for this project with the 608a, while I like it, is that it's a NDA datasheet :/
**\<msvb-lab>** sarang: It's possible the sec eng IC mix we get can do quite a bit with low mem and low power.
**\<sarang>** msvb-lab: ha, nice try
**\<msvb-lab>** We won't get lucky enough to use an easy I2C IC for ed25519, but we can use one of those for a number of other security games.
**\<jbdatko>** PBKD2 I don't think would do well on an ARM M4. I don't think it's memory bound but it takes seconds on a i7. to get the same number of rounds it might take a very long time
**\<msvb-lab>** I shamelessly copied Josh's concepts to our proj mgmt task 166:
**\<jbdatko>** Although TREZOR does some kinda of PBKDF so I might be mistaken
**\<msvb-lab>** https://taiga.getmonero.org/project/michael-rfc-hwallet-1-implementation/task/166/
**\<kamminke>** I would even prefer asymmetric crypto for the keys, the host encrypt with the public key the key to store, but only the right wallet with his private key can open the stored keyring.
**\<i-a>** m2049r[m]: https://docs.mattermost.com/install/install-debian-88.html this, really?
**\<msvb-lab>** jbdatko: A second on key generation, derivation, or verification?
**\<msvb-lab>** I would assume those are all very different benchmarks.
**\<jbdatko>** PBKDF2 on high end processors takes seconds by design to derive the key from the passphrase
**\<m2049r[m]>** i-a: no! this: mattermost.getmonero.org
**\<sarang>** you can the number of rounds to take as long as you want based on estimated processing speeds
**\<sarang>** \*you can tune
**\<rehrar>** alright everyone. Settle down. Settle down. I know it's been a crazy meeting so far, but we got more to get through.
**\<msvb-lab>** There's plenty of crypto going on in #monero-hardware-aside, for extended discussion about that.
**\<rehrar>** Let's wrap up our discussions on the Etherpads and come back here for:
**\<rehrar>** 14. Free to choose topics (Q&A)
**\<m2049r[m]>** i think what we are aiming for is preventing a casual thief and his hacker friends from access to your funds. anyone else will lock you in their cellar until you tell them the passphrase/key.
**\<msvb-lab>** It would be nice to give folks a chance at asking 'how do I use my new holiday prototype device?'
**\<msvb-lab>** I assume it's clear what's been given out in the package:
**\<msvb-lab>** https://taiga.getmonero.org/media/attachments/0/9/e/f/c3076b82874b6d9805dfcabca2c31e78e884536d2e98b54d3b4abc4045d0/protojulcan-2.png
**\<msvb-lab>** And that the screen plugs in this direction:
**\<msvb-lab>** https://taiga.getmonero.org/media/attachments/8/b/a/e/9b16894e088ee64c505dbf0fbc15788e8c5bfb18b1e0ead7056d7acf6332/protoledjc-0b.png
**\<anhdres>** m2049r[m]: there should be a second (fake) password that shows a decoy wallet
**\<i-a>** m2049r[m]: trying pm mattermost
**\<msvb-lab>** ...and that each of us who received a prototype must have read a disclaimer stating that it does not support hardware wallet functions.
**\<msvb-lab>** It's useless for storing value.
**\<msvb-lab>** rehrar: Do you have comments or questions for revuo?
**\<rehrar>** I'm starting to block it out, so not yet.
**\<rehrar>** Last month was completely monopolized with multilingual implementations on Kovri and Monero websites
**\<rehrar>** *cough* luigi1111w almost time to merge?
**\<rehrar>** I'll be back here in like two days though :P
**\<rehrar>** I wish I had questions for this meeting, but I'm sorry that I don't atm.
**\<rehrar>** I do have a question though:
**\<rehrar>** I did (or didn't?) receive a prototype board, what now?
**\<msvb-lab>** rehrar: It's clear a lot is going on in your corner, not to mention multisig work, globee, and ebooks.
**\<msvb-lab>** Man.
**\<sebgus>** rehrar: I'll hook you up with one.
**\<msvb-lab>** My impression is that test folks don't take to IRC well, so it seems we don't get questions from them.
**\<msvb-lab>** sebgus: rehrar was retyping the text out of the agenda.
**\<msvb-lab>** Ha.
**\<sebgus>** aha
**\<rehrar>** And a followup question to that: How do I create a pull request in the official Github repository?
**\<rehrar>** This is where msvb-lab says "I'm glad you asked," and then explains in song and dance
**\<msvb-lab>** rehrar: Ah yes, we can do a pull request tutorial.
**\<msvb-lab>** We even have the pro teacher right here with us.
**\<msvb-lab>** Ms/Mr pro?
**\<msvb-lab>** First of all, is there at least one person who wants to know how to get their sekura/kastelo changes into the official repository?
**\<msvb-lab>** There needs to be at least one indication 'yes' or else we do no tutorial.
**\<anhdres>** I already did once for the logos, I guess I'll do the same again in the future
**\<tat>** msvb-lab: is this about how to make a PR ?
**\<m2049r[m]>** yes
**\<msvb-lab>** tat: Yes, have you ever made one before?
**\<msvb-lab>** Okay, lesson starting.
**\<msvb-lab>** Where is sebgus and i-a?
**\<tat>** msvb-lab: i make about 3 a day, i work as a software developer in my day job.
**\<rehrar>** lesson = https://try.github.io/levels/1/challenges/1
**\<msvb-lab>** So if I want to make changes to the sekura/kastelo official repository, I first clone it to my own GitHub user account (I must be signed in to already.)
**\<msvb-lab>** https://github.com/monero-project/sekura/
**\<sebgus>** I'm here!
**\<msvb-lab>** I clone it in the usual way.
**\<msvb-lab>** Since I like the command line, for me this is:
**\<m2049r[m]>** i another question; qhats the status of the self-destruct idea?
**\<m2049r[m]>** have
**\<msvb-lab>** \$ git clone https://github.com/monero-project/sekura.git
**\<msvb-lab>** cd sekura
**\<msvb-lab>** Now I make changes:
**\<msvb-lab>** \$ vim weirdolameness.txt
**\<msvb-lab>** Now I commit:
**\<msvb-lab>** \$ git commit weirdolameness.txt
**\<msvb-lab>** ...which puts changes into only my personal cloned copy of the official repo.
**\<msvb-lab>** Actually I missed a step which is:
**\<msvb-lab>** \$ git push
**\<rehrar>** If you need more help with git or github, you can ask many people here
**\<msvb-lab>** These things are all basic to any git (this is not yet GitHub pull request specific)
**\<msvb-lab>** Now comes the specific part...
**\<rehrar>** I'm sure we'd be happy to lend a hand
**\<msvb-lab>** I navigate to the official repository:
**\<msvb-lab>** https://github.com/monero-project/sekura/
**\<msvb-lab>** and click next to 'Branch' on the left side the button 'New pull request.'
**\<msvb-lab>** That means, click the 'New pull request' button.
**\<msvb-lab>** Can somebody else explain the rest, I actually can't remember what follows.
**\<rehrar>** After you click New Pull Request? You type your changes in the provided box, and click "Submit Pull Request" or something
**\<rehrar>** there may be requested changes by the maintainer, but that's pretty much it
**\<tat>** You should add a short title explaining the PR content and some meaningfull description of the changes.
**\<rehrar>** alrighty peeps, we're 5 minutes after
**\<tat>** The smaller a pull request the betterm usually one change at a time. It is easyer for people to review those changes.
**\<msvb-lab>** rehrar: Yes, let's close the door.
**\<msvb-lab>** Anyway, regarding PR, please read:
**\<msvb-lab>** https://github.com/monero-project/sekura/blob/master/CONTRIBUTING.md
**\<msvb-lab>** https://github.com/monero-project/sekura/blob/master/PULL_REQUEST_TEMPLATE.md
**\<rehrar>** I think it's about time to wrap up so we can move on in this little ordeal we call life
**\<rehrar>** Thanks for a fun, if not somewhat chaotic, hardware meeting
**\<msvb-lab>** Kerchunck. Gavel landed.
**\<rehrar>** We'll hopefully havae another one sometime soon. As needed basis? Once a month?
**\<msvb-lab>** rehrar: Maybe, I guess regularity might be nice.
**\<rehrar>** You are all released from servitude. Have a great rest of your day.
**\<msvb-lab>** Not sure what others think. Should we just meet when there's a lot to talk about or regularly?
**\<rehrar>** We can try for next month?
**\<rehrar>** Regular XMR meetings happen once every two weeks. Think that's too much?
**\<anhdres>** nice talk eveybody!
**\<msvb-lab>** rehrar: Yes, we'll do that. But unlike sgp's flow it is not part of this meeting to decide the next.
**\<rehrar>** it might help there not be so many topics and discussions to crunch into one meeting if it was regular
**\<rehrar>** Meeting is technically over ;)
**\<rehrar>** So we are outside meeting flow atm
**\<msvb-lab>** rehrar: Cool beans.
**\<rehrar>** and discussing this casually
**\<kamminke>** every 2 weeks is fine - enough time to has something to show which is new
**\<msvb-lab>** kamminke: I think you're right, and instead of a sgp style decide during meetings we'll keep the email/doodle vote. You think that's okay too?
**\<i-a>** msvb-lab: I am here! Was setting up something on mattermost.
**\<rehrar>** Ok. We can do another doodle
**\<rehrar>** Alright, catch you all later.
**\<i-a>** I like doodle voting also, but I will also try to make firmware meeting next friday. I will inform abut it in monero-friendly channels around.
**\<m2049r[m]>** msvb-lab: hows the self-destruct idea maturing? i think thats the only way to be secure.
**\<msvb-lab>** m2049r[m]: Thank you! You're the only one who has taken interest in my wild james bond action feature so far.
**\<msvb-lab>** I think it's actually possible, but a number of research steps are needed.
**\<tat>** msvb-lab: how would it be triggered ?
**\<msvb-lab>** For example, it's going to be real hard to pass enough current through those tiny wires in order to destroy the whole die without simply burning a VCC line or something.
**\<msvb-lab>** tat: I assume a combo of caps, fuses, and a relay will do the job.
**\<msvb-lab>** That is the idio prehistoric concept though.
**\<tat>** msvb-lab: but what is the triggering event
**\<msvb-lab>** There may be a much more elegant solution, we just haven't started researching it enough yet to know.
**\<msvb-lab>** The triggering event is typically a timer.
**\<msvb-lab>** Use case is a honest person like you or me crosses a border and is searched.
**\<msvb-lab>** But before doing so, we set a timer on the wallet.
**\<msvb-lab>** Seven minutes, twenty, whatever.
**\<msvb-lab>** After which time, the cap charges, discharges, and burnes an important circuit like the secure element.
**\<msvb-lab>** Crazy no? I'm really not sure it will work.
**\<tat>** msvb-lab: i have been reading up on stuff the last days, and there is virtually nothing really good without NDA to secure the keys, the only really good thing that is out there are smart cards.
**\<i-a>** tat: could you please give me a link to some smart card element worth considering?
**\<m2049r[m]>** cant be difficult to put a smartcard reader in there - they cant be attacked?
**\<tat>** i-a: well there is allready a bitcoin implementation
**\<tat>** https://www.ledgerwallet.com/products/6-ledger-unplugged
**\<tat>** they discontinued that product because of NFC problems
**\<msvb-lab>** tat i-a: Smartcards brings us into Javacard world, not sure we want to go there.
**\<sarang>** when has java ever gone wrong
**\<msvb-lab>** tat: Do you think those NFC problems could become ours as well?
**\<tat>** msvb-lab: i know java sounds ugly, but it can be pretty safe
**\<msvb-lab>** We need to learn from their mistakes.
**\<tat>** msvb-lab: we wouldn't use NFC
**\<tat>** we use the smartcard processor, there are plenty of wyays to cumminicate
**\<kamminke>** Smartcards running a small OS, which runs a hypervisor, inside there is another OS and the JavaVM .. I thinks it is security through obscurity
**\<tat>** i show you guyes something:
**\<tat>** https://ftsafe.com/Products/BlockChain
**\<tat>** you can call it security by obscurity, and when it comes to the die it always is, but these stuff has been hardened for decades.
**\<tat>** It is very very difficult to build a good and reliable attack against that kind of devices.
**\<kamminke>** Well, your passphrase you can lost in that moment the friendly border officer requested it - your fingerprint he gets with a twist of your arm..
**\<i-a>** (I really LIKE so many opinions here, well done:)
**\<msvb-lab>** i-a: Pretty cool, no?
**\<msvb-lab>** And I even think the etherpads thingie went okay. We won't do it every time, but at least the seasoned meeting participants know how it works now.
**\<msvb-lab>** And anyone can jump into those pads at any time before, during, or after a meeting.
**\<msvb-lab>** I'm out of here, going afk. Have a good one everybody. Thanks again.
**\<kamminke>** I like to investigate, how Lattice stores the configuration for the iCE40 FPGA on the die - we are talking about 40nm transistors, which is fair below the Abbe-limit, no optical microscope helps anymore.
**\<msvb-lab>** @+ 73 chao pescado
**\<msvb-lab>** I'll put minutes up later, unless somebody else wants to do it. See the wiki/meet/ page.
**\<i-a>** kamminke: i am not sure if yu know clifford.at, but this guy seems to be incredibly aware of everything inside lattice FPGA, maybe ask him..
**\<kamminke>** I already talked with him at 34c3 - he gives us support for Dual-Rail Logic while synthsis, if I give him a very good analysis how I can avoid power analysis with that technique
**\<i-a>** ok,)
**\<kamminke>** BTW, the faitian wallet use the smartcard from infineon - I remember this are the company with the weak random generation last month in the tech news, right?
**\<jbdatko>** It was an RSA attack -- ROCA I beleive
**\<i-a>** i must go, thank you all for nice inputs and see yu next time:)
**\<m2049r[m]>** kamminke: please tell me why power analysis is relevant here?
**\<tat>** m2049r[m]: could that be related to side channel attacks by listening to the power line?
**\<tat>** And one more question, i have seen that there is some research into using an FPGA, isn't that kind of die horribly expensive compared to other options.
**\<m2049r[m]>** tat: as i understand it, yes - but think it is irrelevant - because if this attack is useful, the attacker has already made the device do something with the key. so they might as well make the device transfer the funds out.
**\<m2049r[m]>** other options seem to be thin.
**\<tat>** i have one of the small devboards, and i connected the usb-c connector to my macbook power supply, it wouldn't work, only if i use an adapter with a regular usb power supply.
**\<tat>** Is it possible that the usb is actually a usb interface with a usb type c plug, as far as i understood usb-c uses a protocol to handle the voltage needed
**\<i-a>** tat: Yes, it is just normal usb rewired to usbc. Usbc funkcionalities are not implemented.
**\<tat>** i-a: so usb-c plugs won't work then, you will always need a adapter to micro or something and a usb psu
**\<tat>** i-a: i mean usb-c cables won't work
**\<i-a>** no,I am using original usbc cable and it works.. probably there is something how apple handle usb, it probably recognises usbc and is expecting something different..

386
_posts/2018-01-12-logs-for-the-Hardware-firmware-meeting-held-on-2018-01-12.md Normal file
View file

@ -0,0 +1,386 @@
---
layout: post
title: Logs for the Hardware Firmware Meeting Held on 2018-01-12
summary: Discussion of the firmware for the dedicated hardware wallet and a discussion of Ledger's approach
tags: [community, crypto]
author: dEBRUYNE / fluffypony
---
# 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