So I just want to emphasize that while it may have felt negative what we were pointing out all the challenges, I just, I think that's just where we are. It's the dynamic nature of the data and the data isn't just a research study. It's actually being delivered in clinical care. So this is just where we are and I think the point of the discussion, I'd like to stay focused on well how do we try to solve some of these? Where are the gaps and are there ways that we can use existing cohorts in existing studies to help understand this or do we need to do some additional studies to help solve some of this dynamic nature and reporting back and the care? So with that, I'll open discussions. Rex. So the other thing I think that we constantly struggle with here is what the definition of action ability is. And so I was really struck several of us had the pleasure of being at the ClinGen meetings just a couple of weeks ago, last week maybe. And there was a presenter there who doesn't routinely come to these meetings who was a parent who talked about a sort of crowdsourcing approach to help get information about variant in his child for which there was fairly little known. And the take home message from that which I think would be great to stimulate some discussion is he argued that we should get rid of the term action ability because his argument was by sharing that information and just making it available, he was able to engage a basic site, you know, back to a virtuous cycle, he was able to engage a basic scientist who actually helped them figure out what the biological basis of the condition that his child had was, he was able to identify something like 50 other people around the world that had this condition. And I think if I remembered it correctly and somebody who was there could correct me, he's actually even gone so far as to think about how you could produce some of the biological material that if provided back to his child might actually have a therapeutic, a positive therapeutic effect. So I was really struck plus it was an amazing presentation but I was really struck by the case that maybe we're not even thinking about action ability correctly in a lot of these cases and that goes far beyond whether we can just sit in front of somebody and say oh well, you know, you're at increased risk for this disease or we'll give you this drug but this guy went out and did a lot of action based on something where many of us would say there was no action ability. Howard and then Mark? Yeah, I wanted to respond to that because I saw the same presentation. I mean, and I understand where he's coming from and I think those of us that are in the clinic never would say there's nothing we can do with this information but I think this gets at what Jeff had introduced as the concept of, you know, personal utility which obviously was incredibly rich for this particular individual and utility that payers and others pay attention to. So as much as it's really enticing to think about jettisoning the idea of action ability, clearly there's going to be some utility to using action ability or utility for certain audiences. So again, this comes back to the idea of we have to understand the context with which we're using it. I would also just point out that a lot of the points that we're bringing up around the role of the patient here are going to be explored in panel 9 and so I think that it would behoove the panel 9 folks who I know are paying attention to this to perhaps pick out some of these comments. We not spend a tremendous amount of time discussing them now but that could reframe our discussion at the end of the meeting tomorrow. So on a different aspect of what you're presenting, I was trying to think of examples where this problem has already been solved where there's data today, the data tomorrow maybe or maybe not different. We have to be able to circulate it and figure it out and, you know, on the genomic level we're trying to figure out for our own institution because of both the clinical part and the liability that is there. But there aren't that many examples in medicine where the quantity of data has to be longitudinally reassessed. You know, yes, if someone has poor kidney function you note that when they come back to see you later but it's not the same. And the only thing I could come up with was around what the grocery stores do where they, when I go to shop, but yes, every once in a while I do. It, they know a lot about me, my past and they see what I'm doing today. They make changes in their algorithms based on what I do and feed forward. And yes, my purchases for my 16-year-old daughter does make my profile slightly different than it would be otherwise. But it's still, there is this kind of iterative loop that is in place. Now, there's monetary reasons why they do that. But they're handling mass data in terms of, and I'm wondering whether we need to look outside of medicine to get some examples on how to handle this. Because really that's where we are is this sort of loop. But it's, there's just not a clear path to follow. The EHR is not going to give us what we need for this. The data, the way we're doing it today is not. So we need something much more creative than just a small iteration. So I think that's a good point. And I do believe there are other places we can get help in this space. But I think the challenge is the reporting side of it on the clinical, right? That's a little, so I think there's a little bit of a difference in that, you know, you should be buying self-magazine today, Howard. Versus, oh, that gene that we reported out is not the same one. So I mean, but I agree. I mean, I think we should look at some of the other technologies. We had a question here, comment. I was just going to comment that the space between marks, following up on Mark's comment, that the space between clinical action ability, from a payer standpoint and personal action ability is potentially filled by research action ability. So that's, I think it's quite relevant. And then the second quip is that, you know, in terms of all that high data, amount of data that there may be some NSA servers available quite soon. Yes. One of the big problems that I see in achieving all of these goals, whether it's, you know, longitudinal data, preventing health disparities, re-contacting patients when new information is obtained from, you know, about variants, is the need for unique identifier numbers for babies born in this country.  Because of the transient nature of a lot of our population. And so I know this is something that, you know, I've been on group studies that have been talking about this for years now, and it's still not been implemented. And I really think that, you know, not that it's something that we can solve here, but on the national level as we go forward with personalized medicine, you know, there's a real strong need for that. And maybe I could ask if the slides could go back up. Howard asked, in regard to this specific question of the dynamic nature of these data, and I think we actually need to get to Howard's slides. The one where you asked a series of questions about, you know, where you store the data, who does the reanalysis, what's the rate, what are the criteria, who pays for it, that sort of thing. I think there are some labs that have some experience with this that could comment. But it may well be something that we want to struggle with a bit. And again, where are the research questions there, since that's, you know, sort of our bailiwick. So Rita, you need to bring up Howard's slides if you could. I know you're probably extraordinary. But maybe Heidi could, or Sharon or others could comment on how you deal with that. I can comment from the Baylor exome experience where we, and we, some of it was in our JAMA paper. It actually is a reasonable proportion of the diagnoses are made from very newly discovered genes. So that's in children, predominantly a pediatric population, although not entirely, and again, predominantly neurodevelopmental genes. And we definitely do routinely re-evaluate the data and report back. But I would say that I think if you look at medicine overall, we tend to just re-order tests. Because, no, but I mean, for good reason. I mean, you wouldn't want to re-evaluate an MRI from five years ago. The MRI resolution is so much better now than it was five years ago. And so I do think we spend a lot of time talking about re-analysis of data, but I actually think the exome certainly continues to get better, and even the genome will get better in terms of our ability to detect triplet repeats and things like that. So I think we're more likely to just order a new test with better technology than to try to find data that's five years old. So my, our impression is that the re-analysis is relatively time limited within the first couple of years and with response to the other comment, because it's also extremely hard to find people. They don't have the same doctor more than two years later. So I'll add to that. I completely agree with Sharon when you're talking about re-analysis of raw data that you might as well in most cases re-order the test. But another paradigm is when you've already reported and interpreted a variant and that's sitting in a clinical report, how do we maintain knowledge on those reported variants over time? And, you know, about five years ago we launched a new software system so that I don't even have to re-analyze the data. If my variant database updates, it will automatically send an email to the physician, update the report. It could do thousands of reports behind the scenes without me doing anything. And that has been an incredibly valuable system. It's been the subject of an NIH study and quality care that David Bates led. But the single biggest barrier for us rolling out this system was getting a lawyer to sign off at each institution that they would accept the fact that the system did work automatically. And we could not get most institutions just to have a lawyer sit down and sign a contract. That was the biggest barrier to launching this widely. And it was, I sat there and said, the liability you could incur, because you are denying patients to get the reports updated is far worse than what you're looking at. But it's been a huge barrier. I think this sort of comes back to an assumption that you made at the beginning of your talk, which was that everything is gonna move towards a whole genome sequence. And I just wanna kind of push back on that and maybe we should re-evaluate it. I think as we learn more and more about the biology of disease, we won't need to do whole genome sequencing for more and more types of patients. I think even hereditary cancer is one example where these panels that we have now are effectively as good as doing whole genome, whole exome sequence. We don't learn anything more from doing genomes, at least in a clinical setting. Now this is putting aside research questions, but I think the same thing will be true for many different Mendelian disorders as we answer, as the Mendelian Center solve all of them, we just need to have a really good clinical panel and don't need to then generate all of the rest of the data, which then causes all these problems. And so I think that's something that we ought to keep in mind is that whole genome sequencing is not necessarily the answer to genomic medicine and implementing it in the right way. So it might surprise you that I slightly disagree with that. I think the big issue is that there is a transition, in my opinion, away from we test for specific purposes till we do a broader test that enables us to use it for more purposes. So as an example, if you only use a panel for a specific indication, it is only useful for a specific indication. If you spend the resources to do the whole thing, then you have the ability then to leverage that across multiple indications because you don't know what you're gonna be back in for. What we do know is our model of the past has been tests for what I'm seeing and reimbursed for what I'm seeing. And I think the challenges we're talking about here are really around the fact of, hey, let's do one wet lab test and then the follow-up analysis is now going to be on the analysis side. And so the testing then is done slightly differently. The wet lab isn't re-incurred over and over again. So I think that's a price point, but as the price gets lower and lower, I think you're gonna see increased use of this for the purpose of using it for other indications down the road, as an opinion. Certainly understand that perspective. I think that as more and more applications of genomics become clinically useful, right? And there's defined advantages to doing them, then those will become part of clinical care. And we're gonna have a much better time showing defined evidence for use of a particular type of data than we are to say that whole genome sequencing is useful, right? And so I think we really do need to still focus on the indication-based testing and not just assume that we can solve all the problems with one test. So I think that's a great discussion. I'm not gonna comment on that. I'll leave that for others. Heidi, did you have a question or you wanna add on? I was just gonna build off that comment because I sort of agree with both perspectives. Technically and economically, I actually think moving towards the larger platform is the way to go. But I think there needs to be a much more definition between what is ready to be returned in a clinical context and what should really be saved for research analyses and then later when clinically relevant could be pushed back into the results. And so I think I'm all for using the full technology at the start once it makes costs sense. But I do think we need to do a better job in deciding what is ready to go back to a patient at each point in time. So I agree with what's ready to go back for the patient at each time, but I do wanna remind everybody that the limitation we have on variation is not having enough variation measured. So as long as we keep delaying sequencing more and more, we have less power to answer some of these questions. Question? I was just gonna say that I don't think that the two approaches, the entire genome approach and the indication approach are mutually exclusive approaches. I think you can design a system where both will work effectively. Other comments, questions? Terry? So I wonder, and I might ask Gail to comment. You made it, what to me was a bit of a surprising comment earlier this morning, which had to do with insurers would rather pay for a single test rather than multiple tests because they're going to incur longer term costs, which is the first time I've heard somebody talk about longer term costs when it comes to paying. But it seems as though that would be a question that an insurer would ask then, oh my goodness, if you're just testing the X gene, it's a whole lot easier than if you do the whole sequence and I have to deal with that. So is there research to be done around that question to demonstrate that yes, it actually is either more cost effective or that it improves outcomes, which is really what they're after from what we've heard. Yeah, so I think there absolutely is research to be done because again, the insurance companies respond both to the research, but also to practice guidelines. And so when the GI doctors publish practice guidelines or the cardiologists publish practice guidelines, they need evidence to base that on. I will say what a lot of the labs do now is I think our cancer diagnostics, we run one panel. We just, you order two genes, only those two genes end up on the report. But if you, it's sort of like when you order a sodium, they actually run the whole chemistry panel, they only tell you the sodium, but if something else is abnormal, they do tell you, we do that. So it makes it hard to do cost outcome measure if on the slide, usual care is actually adding those incidental findings in, but there are ways. And I think it's a really important question because the insurers are so afraid of VUSs. I mean, it's just a fascinating conversation. They're afraid of not just testing, but inappropriate operations, et cetera. I mean, they have some reasonable concerns. Katrina? Yeah, I just wanted to add, Terry, that I think that is an opportunity for the idea of coverage with evidence development to have the payers pay for the test for the thing that they wanted to learn about. And oftentimes it's not really very much more expensive to get a whole bunch more of information. But as long as they don't get it back and that information is being used for the research purpose, then they may be willing to pay for that expanded test. There may be a way to capture what's already going on in labs because many labs have this model. I assume Heidi has a similar model of they're running more than the person ordered. And honestly, from me in colorectal cancer, we were ordering Lynch genes and we have so many TP53 mutations. And that's one of the things that worries me about these neuro panels. You're only testing the genes you know, you're missing the genes that you don't know. And when we started doing a broader panel because we were doing Broca with the breast, then oh my God, we're hitting all these colon cancers on TP53 and it's become significantly recognized that that's an associated gene, but that's not something we thought about. Well, and I think while it's important and reassuring to know that we could get some help in paying for the research, I think it would be helpful to have this group really help us to address what is the research that should be done. So what is the question that we would want to address and can you kind of flesh that out for us? Yeah, okay, yeah. So I mean, I think the very specific question of what is the added benefit of having those other genes versus what is the added cost of follow up? And so the added benefit, you can find an existing data, but those VUSs are not reported and followed up under existing care. So you would need to randomize people to beginning return the VUSs and not beginning return the VUSs, for example. So in the UDN, our proposal had put out to do whole genome sequencing on everybody, but only return exome sequence initially and then reflex into whole genome if we didn't find it on the exon. But what's interesting is most of the clinical sites are saying, well, we actually don't want the exome then, we want the whole genome. So I think there's a question of how do we test this? So if you have more data, are people gonna want the more data versus if you only have a limited data, well, you're gonna take what you can get. So I think there's a challenge in exactly how do we test those things. Just in our case, I thought people would say, great, just give us the exon data and if you don't find it, then we'll reflex into it, but we're finding people want the whole genome. I would also say that I think there really is a need and this is, I think, directly in NHGRI's neighborhood of the best way to educate physicians about variants. I think that many people have argued that they shouldn't be reported at all, but the current ACMG guidelines still recommend that variants be reported but characterized that way. And so really figuring out how physicians should understand that they really shouldn't act on them. What is really the most effective way to have physicians really understand the meaning of them outside of the core medical genetics and probably cancer genetics community is a huge issue and will decrease costs if we could better explain to our colleagues, these mutations are only here because in the future we may learn more about them and they're not something to act on now and I think there really needs to be research in, there already has been, but I think they're in the context of large scale testing, there needs to be additional research because the panels do generate more variants. I mean that data has been clearly documented in many scenarios. Cardi? One thing I will say is that one of the reasons that we recommended returning the VUS is because there are things that can be done, for example, segregation studies in hereditary cardiomyopathy is one of the best ways to rule in or rule out a variant could be done in hereditary breast cancer and other things and so there is action that a physician could take to say, oh no, that was the wrong one, it didn't segregate in the other affected family members or yes, that's it, we've now tested 10 affected family members, although the families aren't often that large, so I think, but I think the laboratory has a role and responsibility in being very explicit about what those actions could be that would help inform and I don't think that's always done. Mark? Yeah, I'm gonna presage a little bit of panel four here because there have been a number of themes that I've been writing down here that have been coming out that there may be an opportunity for a synergy in terms of the right place. So we've heard about the difficulty with the longitudinal nature of patients and how to capture data, how do we utilize quality improvement. We've talked about economics which I would prefer to characterize perhaps as a value proposition, training and now we're talking about testing what is the long-term cost of returning variants versus not returning variants and the challenge that we have is where do you do that and we have an opportunity and have had some preliminary discussions with the HMO Research Network which will soon be called the Healthcare Systems Research Network since HMO is becoming an anachronism and the Genomic Special Interest Group that's been organized as part of that. HMO Research Network consists mostly of integrated healthcare delivery systems that have embedded research within the operations and all of the different issues that are coming up here are already incorporated into that and so I think if what emerges from this meeting is that these are the areas we need to focus on then the question really becomes well, who has the best ability to get all the data that's needed to answer these questions and that may be the direction to guide conversations with how we might engage with the HMORN to accomplish some of these important research question. Anything else? Yes. I think on the educating clinicians about variants it's not only the VUSs but it's basic patterns of inheritance. Just as an example I was contacted last week by one of our neurology fellows who said oh can we get genetic counseling for this family, a baby with intractable seizures and the genome panel returned a result in a known epilepsy gene and when I looked at the report it was a heterozygous variant thought to be pathogenic but in an autosomal recessive condition with no second variant found in the other allele so I think there's a great need for genetic education. But I mean to be fair those are ones that I look at and scrutinize because you can't call the copy number variant on the other allele out of the exome data and if there's a tiny deletion there that involves the other so these are important signals so it's really not straightforward so I would come to the defense a bit of the clinicians in fact I would much rather have them ask that question so that we could do the appropriate clinical interpretation I don't remember who had mentioned this earlier but this is a huge area where the people that are in the clinicians that are returning this there's a huge interpretation thing where we can't take what the laboratory is sending us as gospel it's up to us to also do some additional interpretation in that context. Teri. And maybe to follow on Mark's comments as well as those of the study we should do the added value of the whole genome testing to some degree we'll address that in UDN but it's my recollection that at least a couple of the end site projects are asking this question and maybe MedSeq as well so aren't some of you randomizing people to either the screening panel versus sequencing or the limited versus general and yet those are small studies so can those be sort of pilot data that could then lead us to and maybe you could talk about what the outcomes or what your end points are for those studies. Yeah thanks on MedSeq I didn't mention it but we have an arm where we're taking cardiomyopathy folks and looking at them with whole genome sequencing versus the more directed panel testing and at the moment we're not finding greater pickup but we are certainly generating more cost because there are secondary, yeah with whole genome because there are secondary findings that the cardiologists and then the cascade of physicians around them feel must be followed up on as well so that's only one area and I think we're gonna have to look at other areas where there are known variants and where there are more novel variants and there's but I do think that such sentinel projects are useful so that we don't have to do every single variant in every single gene. Yeah so we are also doing randomized control trial with economic outcomes and we have not analyzed our data completely but the difference really is more in the incidental findings because the usual care for colorectal cancer is a pretty big panel right now but we actually have data that we just submitted at SHD on novel genes that look like they're involved but for the incidental findings the number one thing you find are BRCA one and two and whereas there is certainly some cost into following those up there is a benefit to having followed them up. If I may follow up, this conversation reminds me to have a point I make often which is the difference between discovery and clinical care and we are so much at the forefront in our respective institutions that we are often blending the clinical care and discovery so when we talk about finding a novel variant and then going back into the family and trying to discover by segregation I don't think that's a scenario that typical clinicians are going to be faced with when with typical integration of genomic medicine so I mean we don't want to think about homogenized bad care going out into the world but on the other hand I think that we should make some distinction in our minds between what we would expect clinicians and their patients to be dealing with sort of across the general standard of medicine versus what we do at the cutting edge. Although I would argue that in the implementation space that we, these are questions that are gonna have to be tackled because it's not business as usual where we just send it back and we don't expect the clinicians to do this we don't know what the right mechanism is to address the issue that we were just talking about a couple minutes earlier but that's a very important issue to develop and ultimately it will have an impact in issues that really do matter to healthcare systems which is what is my liability for delivering this kind of care and what's the standard of care and we have a role I think in terms of defining what that standard could be. Up front. So, in the back, up front please. So, Wendy, sorry. Yes, since this is so much a matter of education I thought I'd put a word in for our work group which is the, related to the ISCC work group which NHGRI convenes ICs and professional medical education, medical groups. So one of the groups that presented to us was called TRIG, the Training Residence in Genomics and it's largely speaking, I believe, to pathologists. I know Terry went to one of their workshops and they have the very impressive way of teaching residents how to interpret genomes, well, variants at least. And I don't know where the answer is as far as whose role it is, it's at the very, very, very specialists to deal with these variants and have wonderful knowledge or do we need to, I think, disseminate it into trainees. It does worry me a little bit as a geneticist that this is going on so strongly in the pathology world and I don't see a correlate in the genetics world. But at any rate, I think there's a lot of commonalities that we could learn and it strikes me if this group or people who are deep into the projects could see how this is being disseminated, you could inform each other. So we'll talk more about that later, I think. Mike. I disseminated along the dissemination pathways following that train of thought that I think as a practicing cardiologist, and where do I get most of my education and where are guidelines or guidance comes from within this, often within the specialty. And so some of these things are not, there's certainly universal concepts that'll be fine for all of us to better understand Mendelian genetics again. I don't know if the acronym TRIG might scare some of us. But I thought we were past that. But I think that a lot of us do need to integrate the utility of particular variants within the context of our specialty practice. And I wonder even if there might be the same variants that would have a different context would get a different set of educational priorities for a different clinician. And we're gonna talk about that a little bit in the tomorrow and in a panel eight discussion here. Thanks, Howard. You wanna summarize a little bit? Or are you done? Or are you done? No. Lunch. No, I think the conversations were very helpful in thinking about the whole range of activities, ranging from what types of testing are we doing, from panel to genomic data, to looking at what's axiability and utility. I think those definitions, in context of who's gonna be providing the care, is really what's gonna help determine how we're gonna do the reanalysis and provide the data back. I do think it's clear from the discussion there's a lot of work that needs to be done in looking at how do we do this, looking at the cost effectiveness of this. And I do think some of the programs currently in place have the ability to do that. I guess my question then is, is the field moving fast enough to pick up on some of the return questions down the road? And I'm not sure how many people have that, but I think that's an area where we for sure could leverage the existing cohorts and studies that are going on as to how does the data come back in. Thanks to the whole panel. Appreciate it. Do you wanna mention the... Okay, so yeah, so thanks Howard. You're allowed to sit down now. Thank you very much. And thanks to all of the panels. This has been a lively and fast-paced meeting and that's a good thing. In terms of the lunch, we actually would like to take a picture of everyone. As you see, we show those at multiple meetings, et cetera. And that is on the way to get the lunch. So that's a good thing, because you'll all be heading in that direction.


Derek Henry, except he's 5'3", 99 speed, 99 acceleration. Oh, he's so many. Look at him.  Touchdown. He's too quick. That's a touchdown. Let's go baby Henry. Get to that edge. Too quick for you. Too quick for you. Too strong for you too. One more. One more to the edge. He knows what I'm doing. He just can't stop it. Baby Henry. Baby Henry. Shoot. He still tosses people. You better start adjusting. You better start adjusting. They didn't expect it. Too quick. This is so awesome.


Good afternoon. We have our first talk that would be a presentation by Yolande Ramaye. He's a security researcher at Kadaelsky security focusing on cryptography. He's spoken at Black Hat USA, DEF CON and others. Please a warm welcome for Yolande. Hey, hello, I'm super happy to be here today. So my talk will be about one key to rule them all. It has a subtitle in the program telling you it will be about elliptic curve math tricks. And it should not scare you because you were there last year at NSEC when Morten gave his Getting Ahead of the elliptic curve talk, right? So you all know everything about elliptic curves. Nah, I'm kidding. So an elliptic curve is just a set of points basically which satisfy certain equations. Here is the Viostras equation. And I require the elliptic curve to be non-singular. But you don't really need to know all of these today to understand the talk. Which is super important though, is that you understand that those elliptic curves even additionally a group will define on the curve which is well-behaved. It does what you expect it to do when you add two points together. It gives you a third point on the same curve. And now about elliptic curve cryptography briefly you've seen this morning that elliptic curve cryptography is almost dead, right, in the past quantum talks, but nowadays it's almost a big it's everywhere. You can find elliptic curve cryptography whenever you connect to a website and so on. Elliptic curve cryptography is usually working with a set group of prime order M, a huge prime order of the elliptic curve C we just defined. And we have a point on the curve which we call the generator or the base point G. And everything is done in that subgroup, so it's important. Now the security of elliptic curve cryptography is based on this discrete logarithm problem, DLP, which I have nothing to do with the data loss prevention, right. And the DLP basically tells you that if you have a point Q, which is equal to N times a point P, for N a scalar, an integer, it is super difficult to find the value of N if you are only given the points P on Q. Okay, I might have been a bit faster, so what's scalar multiplication? It's exactly what you expect it to be. So two times P, the point P, is just basically P plus P.  And by definition, the scalar multiplication is distributive over the addition. And this is the main point of this talk.  So that might sound a bit scary, but it will be clearer in a little bit. Alright, so we've seen the discrete logarithm problem and now about elliptic curve schemes. We have mostly signatures like ECDSA, key exchange like ECDH and we can even do encryption sort of with the hybrid crypto systems such as ECUS where you will encrypt with a symmetric key algorithm, but you will share the key using public key algorithm based on elliptic curves. So I've just said public key. So what's a public key and what's a private key? Well, elliptic curve cryptography is usually a public key crypto system where the private key is simply an integer. So it's a value k. Here I say it's smaller than P because I want it to be an element of Fp.  It's just like the details behind, you know. The stuff the cryptographer will deal with. And a public key then it's a point P on the curve which is computed using the private key k. Multiplying it with a generator which has been decided by NIST or standardizing bodies or whoever made up the elliptic curve you are using or maybe you can choose a point to use as a base point yourself and just multiply it with integer k. And you will get a point P equal to k times g which will be on the curve. So private key is an integer, public key is a point on the elliptic curve. That's the main point here. And now that you know that, I can go ahead and tell you a bit about Bitcoin. You all know about Bitcoin, I guess. And Bitcoin is using ECDSA, the signature scheme, to basically sign its transactions, but also to generate the addresses. So when you send bitcoins to somebody, you are actually sending them bitcoins to the hash of a public key. And this is important because since it's using elliptic curve cryptography, it can rely on all the NIST structure, the elliptic curve's AVE behind the scene. And somebody, Peter Vughel, proposed the idea of your hierarchical deterministic wallets a while back. And this idea is basically that you can use the math to derive child keys for elliptic curve schemes out of a master key, a parent key. And this has been actually implemented in Bitcoin. And it's used nowadays to derive child keys. So as I told you, the public key is just like what you will hash to get the addresses in bitcoins. And you can do some magic tricks with those public keys, like you can take a public key, which is a point P equals to K times G. And you can take an integer R and multiply it with the base point G. You get the point R times G. What happens if you sum P, the public key, with those newly generated point R times G? Well, you just get another point on the elliptic curve Q. And what is super interesting is that this elliptic curve point is actually the public key corresponding to the private key given by K plus R. That's by distributivity, as I just explained you a couple of slides before. And this is super powerful because you can use this idea to have one master Bitcoin address kind of and derive other keys that you will know the private key of just by knowing the value R. And anybody can send you money to new addresses and so on. And that's something that has been implemented in Bitcoin, in the BIP32. So Bitcoin Improvement Proposal. I might have skipped some details. But it's not too important. The idea is really that you have a private key, which is an integer. In BIP32, they have extended keys, whereas they have an extra value at the end of the private key, which will be then used as a hash-mack key to hash the public key on some index to produce a random value, absurd a random value, which is deterministically generated by the hash-mack, you know, R. And this value R will be then added to your public key to generate a child key for your parent key. And it has been implemented. It is in use in most Bitcoin wallets because it allows you to basically have multiple wallets at once with just one private key. You can handle different addresses and assign the transaction as you need. And this is all based on the ideas that P plus R times G is equal to K plus R times G. There are a couple of things I've skipped, like the idea of ordinary keys and so on, but it's not too important for what I want to present today because what I've been thinking when I've read about BIP32 is, oh, that's a nice idea, actually. What can we do with these beside Bitcoin addresses? And where do we use public keys, actually? Who amongst you has already signed on a server using SSH keys? Most people, right? Who has been using PGP or who has been using modern VPNs, such as WireGuard and so on. All those services or tools are relying on elliptic curve keys sometimes. So it's not always mandatory. You can use a RSA instead or something like that. But for SSH, for example, nowadays, you have a lot of public keys which are based on elliptic curves because they are smaller in size. And actually, the last research we've done with one of my colleagues was about scanning the internet to collect all the keys we could find out there. And we can see that SSH keys are mostly relying on one curve, SecP256. And that curve 25519, a really nice curve designed by DGB which is being used by EDDSA, is naturally used in practice. And that's a good thing for the stuff I will present you now because with EDDSA, you can naturally do the same kind of tricks I just presented you because the private key will be hashed before producing the integer you multiply with the base point. So you will have to compute a frame age which is not something you want to do. So that sounds fun, right? Deriving new public keys out of a private... out of a previews public key. So what could we do with that kind of stuff? So the idea is that you could basically publish your public key and if somebody wants to add your SSH key on a server, but you don't want to, you know, if somebody finds the public key, you will know it's yours or something like that, he doesn't want that. He could just put a new public key generated by adding a random value times g to your public key. And if he sends you the random value he used, you could then compute the private key which corresponds to that public key he generated because you know the private key of your own public key. And this is the idea behind what I'm going to show you shortly. So it's called one key. And basically it's a tool which will take a SSH key and SSH keys can be elliptic curve-based. So I'm using a SECP256R1 public key there and you can use one key to derive new public keys in practice. So it's basically to showcase it's working, what I just said. So let's do this. Not what I wanted. Okay. So one key is made in Go. You can get it on GitHub, actually. And it's quite easy to use. You give it a key, like here is the test key, and you give it what I call a derivation code. And it will produce an integer R, which is here the derivation integer, as I call it. You can see it here. And basically the public child key here is the public key which corresponds to the test ECDSA public key. Plus C1B69. So one times the base point of the elliptic curve I'm using there, so P256. And this is nice because it works here with a private key, but actually what I could do is just here take the public key and do the same thing. And you can see I get the same public child key here. And what I can also do is take another value as a derivation because test two is basically what's getting hash-macked with a secret value which I'm not showing on screen. It's in a config file basically. And you can see here when I change tests to test two, the derivation integer changed. And this is the value R you are adding to your public key times G to get the public child key. And now that's cool, but you need the private key, right? So what you can do is basically just like if you were plugging UB key or something, a smart card in your computer, you can add keys to your SSH agent, which is nice because you can derive the keys, add them to the SSH agent, and then you can just use SSH as you would usually. So now you have one master SSH key and you can derive new child keys on the fly in memory without writing them on your computer whenever you need them. So here I will use a dash-q and this will not work because I use the public key. If I use instead the private key, let me maybe show you, okay? That's what happened. So what does it mean? It means that my SSH agent got a new key added to it, which is called child key test two here. And if I want to add another key, I can test three. And the SSH agent just got the child key test three key added to it. And that key is not persisted into memory. And let me remove all those keys. So I just got the keys I usually have, SSH. Okay, let me try and connect to some server. This should not work. Maybe my internet timed out. Demo effect. Too bad. So the idea was on the server I'm trying to connect to, I have a public key in the authorised keys which correspond to the test two child key. And I could connect to it if my child key is added in my SSH agent, but I couldn't if it's not added to the SSH agent. So let's go back to the slides. You can use it today if you want. One key is a puck, but it's on GitHub. You can go and get it with go get. And you can play with SSH keys. You might ask, what about security? What happened with those child keys? Well, there are two things. The first thing is a child key is not weaker than the private key used as a master key because both are relying on the same ARB-NAS assumption which is a discrete logarithm problem. So if somebody is able to break your child key, you would have been able to break your master key in the first place. Now, what happens if you have a child key and somebody is able to get the private key corresponding to that child key? Well, if he also knows the public key of your master key and he knows the value R you use to derive the child key, he could recover the master key because K plus R minus R is equal to K, right? So that's just plain math. So the private keys are integers. The child key, the child private key is K plus R. If I know the value R and I know the value K plus R and I know it has been derived, I can just compute K. So you don't want your private key to leak, right? Obviously. So BIP32 has a workaround to avoid this using Arden keys. I haven't implemented it for SSH because it's just a POC, it's just a pack, but anyway. What's interesting here is that you can imagine something the other way around. So you have a master public key which you use on all your machines and whenever you get a new machine, you can generate a new private key, K, and you can compute the difference between your master, a new private key. Yeah, anyway, you can compute the difference between your new key and your master key. And that difference will be the value R. And once you've computed it using, you need to know the both private keys to do so. Then you can derive your master key out of your child key whenever you need it. So it can be seen either as a feature allowing you to derive the master private key when you need it and never persist it in memory on your other machines or it can be seen as a problem. If you leak it and the value R you use is also leaked. What could we do with these kind of IDs? It really depends. My first idea was to do a WireGuard key distribution method because WireGuard is a really cool, modern VPN and I like it. And I've seen a lot of people complaining about the leak of PKI and the key distribution method for it. But it uses ED2519 which is hashing the private keys which makes the ID here a bit more difficult because you will need to modify the way WireGuard is using the private keys so that you will use the integer directly and not the hashes which is not really a good idea. Another idea I had with this is that you could imagine some sort of an S run somewhere or basically you run somewhere it's really mean, it encrypts all your files with public key cryptography. And then when you want to get your files back you will basically have to send money to an attacker. But if you send money and it doesn't send you the key you are a bit sad, right? So you don't want that to happen. So the idea will be basically you could send the money to some trusted third party like let's say a smart contract on a blockchain, you know, not really a trusted third party but a workaround to AVE1. And if the smart contract is able to derive the same child keys out of the private keys the attacker will send you it could then deliver the money to the attacker or stuff like that. I'm going to write a blog post about it at some point. It was a fun thought project we had with some colleagues at EPFL anyway. So other things you could imagine is to have disposable keys where you have a public key out there, I don't know, like on GitLab or GitHub. You can see anybody's public keys on GitHub by simply typing github.com slash username.keys. And you see the public key people are using which is privacy-wise a bit bad because maybe you can link some identities with some other nicknames by looking at which private keys, which public keys they even their profile, which is not something you want, right? But what you could do is derive a key out of your master key and if you want at some point to prove it was you who owned both private keys, you could give the value or which is the difference between the two private keys so that anybody could verify out of the public keys that one public key derives into the other public key. So it's kind of like opting non-reputability for SSH public keys on the internet. Not sure it's a thing, but it might be done right. So, yeah, just try it out. As you can see, elliptic curve and math are not so scary. You can do cool things with them and, yeah, if you have ideas, just try them out. It works out well sometimes. Minor keys keep them encrypted because, as I said, if you have a child private key leaking, it might compromise your master key and that's bad. So encrypted keys are supported by one key if you want to try it. And anyway, so the mass collection of public keys we did with one of my colleagues is actually there to help you check if your RSA keys can be batch-factored. You can test them on keylookup.codoskeys.security.com if you want. And you can get the one key software on GitHub as well. And I'll put the slides on Twitter and my homepage at some point in the future. So I don't know if anybody has questions. Anyone has a question? Thank you. That was really interesting. And I can see lots of interesting things to play with here and explore. I'm just wondering is this notion of deterministically deriving keys from a master key, I could very easily be mistaken, but isn't this what happens inside a U2F device? Or is that a different mechanism for creating new key pairs? In which devices? In like a UBiCo or UBiT kind of thing. As far as I know, the current devices which are being used for 2FA and stuff like that, like you have the brand new FIDO2 authentication method which is also based on elliptic curves, is not using that kind of method because they need space to store the key and they just generate new keys on the device. I might be mistaken though. But there are devices out there which are using this method to derive new keys. It's basically the Bitcoin ledgers and Ethereum ledgers. So all those hardware wallets, they usually implement BIP32. So the ID is out there. I'm not sure whether the constructors of 2FA devices are actively using it. If not, they should because it allows them to basically derive as many keys as they want. They don't need to store the private keys on the devices anymore. They can just derive them out of a master key they would generate at first use or something like that. That's a good question. Thank you. Thanks. So you had kind of two ways to compute the deriving factor R. So in the command line tool, it uses the HMAC method using a key that you said was in some configuration file somewhere. But it seems that a lot of the applications, like if I want to make a derived key for you, I obviously don't know that HMAC key and I have to use the raw R itself. So under kind of what are the use cases of using the HMAC with a little short easy to remember string versus when do you have to use the full R and remember some big number? So the idea here is really that if you want to just use it to populate your SSH agents, you can do it easily with large R values by just using HMAC and deriving the integer in that using that. But if you want to generate the key, the public key for someone else to use based on their own public key, what you can simply do then is you generate it as you want the integer or you can HMAC it with your secret value and then you need to release a value R. You need to tell the people the actual value you use for R. Currently, BIP32 and also one key are using the public key of your master key inside of your of the HMAC to have some link between them. But that's why in the demo, maybe I want to be too quick there, but you can see when you generate a key, just like test, it's outputting the actual derivation integer, which you can then use instead of using test 2, I could use dash R and I can give directly the value R to it. And it will derive the same key, so... But in the Bitcoin setting, you don't generally know someone else's public key, you just know the hash of their public key until they use it, right? So then, you can't do any of this until... Yeah, in the Bitcoin setting, the idea is naturally to have somebody else generating the wallet for you, is that you can yourself have a web application, for example, which will generate new public keys for you to unlock later without knowing your own private key. So if you have a Bitcoin, if you have a website selling stuff and accepting Bitcoin, they might not want all transactions to link to their main Bitcoin wallet, you know? They might want each transaction to go on its own wallet so they can monitor it and see whenever it came and if it came, give you the stuff you bought. So it's not the same kind of use case, I would say, but yeah, it's correct that in the Bitcoin case, it's not as straightforward as here. I would just strongly recommend that for the case that you demoed, instead of just using an HMAC to get from effectively a password for driving R, that you also put in a strong password, you know, at PBKDF2 or its successives. Yes, so the secret value has to be strong if you use the secret value as a key for HMAC because otherwise it's not really secure, you know? So I recommend Ezra using big random value as your secret. Or yeah, I could maybe implement some kind of key stretching so that weak passwords will be better, but yeah. Anyway, that's just for the puck. If you want to play with it, you can. It's open source. All right. We have time for one more question if there's one more. Okay, thank you.


Will Warzone last? First, let me explain what this title means. Basically, how long until Warzone dies? Almost a year after its release, Warzone is still one of the most popular games, arguably more popular than Fortnite. So, will Warzone last? If so, how long, and why? The main reason I predict that Warzone will die is if another military-style battle royale releases. I feel like it's going to die kinda like how PUBG did. Let me explain. PUBG fell off in popularity once Fortnite became the next best in. I think once another battle royale takes over, Warzone is going to die, but it's so big surprisingly right now, almost a year later because it's free. It's the best designed battle royale with the most players. Even if another battle royale or first-first shooter comes in, I feel like Warzone will still last, only if it's better than the new game. Kinda like Fortnite when PUBG and Apex were their biggest competitors. People still played it because they thought it was better. But in my opinion, unlike Warzone, Fortnite was able to withstand their competitors because of how big and unique it was. Everyone and their friends played, so why quit? But Warzone will never beat Fortnite's popularity, and it's just like any other military-style battle royale. So I feel like if a battle royale game that looks like Warzone comes, Warzone will lose its popularity. You can't kill Fortnite because no one's game is going to copy building, but if a game copies Warzone, everyone's switching to that game. For example, when Apex was still popular, Warzone came in. It took all of Apex's fans because they were both similar games, and Warzone was just so much more fun. So yeah, in conclusion, Warzone will last until another military-style battle royale comes. Will it die because of this new FPS game? It would lose players. How many players depends on how good the new game is? And let's have a discussion about this in the comments below.


Hobby every EFL teacher needs to try when teaching English abroad, discover local food culture. Food is a big part of the culture in every country. While you can learn a lot about a country when sampling your way through its cuisine, it's even more immersive when you actually get in the kitchen, and recreate some of the local dishes yourself. Cooking classes are a great way to get started. By taking a cooking class in your new home country, you'll learn everything about the country's food culture, the most important ingredients, and the traditional way of making certain foods. No matter if you're a master chef or a newbie in the kitchen, a cooking class in a foreign country is always a fun thing to do. Thanks so much for watching. We are ITTT the leading provider for TEFL and TESOL training courses. If you like this video, please subscribe by clicking that button down here, and click on any of the videos here on the left, for more interesting teaching tips for getting certified to teach English abroad and online.