So we're at 10 19 a.m. We climbed above 60 bucks. You saw early this morning We trade down to a low about 59 45 back up to 60 20 and we're trading right at $60 Nice thing jumping over an 8x $60 happens to line up whether you want the 11 a.m. Expirations pretty good the noon expirations, okay, or we're gonna get the 230 expirations So this will be nice. We'll jump through and hopefully it stays right We're within two pennies right now at $60, so we're gonna look at setting up two sides of the trade right Volatility maybe exposure on each side You have the contract rating at 60 oh two This would be your bullish spread for 11 a.m. From 60 to 61 50 You got about three pennies of intrinsic value there costing 17 and vice versa same thing 11 a.m. Expiration buck 50 to the downside You're selling that one the only difference between the two being that you have about three to four pennies in the bullish side And so you're looking about $30. Yeah, which is 30 cents right away from 60 bucks pretty good for your 11 a.m. It's okay jump to the noons That's pretty cool. Yeah, not bad And let's just see how much more they're gonna charge you so it's been laying here at this 59 60 for five days now So this is interesting now. This is where okay, so about 21 on the Bullish and that's gonna in the bearish is gonna be a little bit cheaper as we take back 20 20 Let's just 20 and 20. It's not bad 40 bucks. So you're looking at 40 cents till noon, right? Now these you have a buck 50 on either side, right? Now the daily is gonna be a big one that you're gonna have five dollars not bad Because you're not gonna have to pay a lot of premium for that extra two dollars three dollars and fifty cents Most of what you're paying for is the ability to hold that until 230. Yes, here's your bullish trade 27 now we're trading right at $60. This is actually all premium So I already know the bearish one's gonna be the same exact price, right? We'll pull it up, but it better be Five five point five point four cents. Yeah, 27. I can already tell 60 minus 73 You know 60 minus 15 73 27, right? So you're looking at 54 pretty cool. Yeah till 230 and You got over about 50 because by 230 oil could potentially move more than a dollar 50 So it is nice to have you know over that level With the IA coming at 10 30 on the dot, right? Particularly at this level. So yeah, let's pull up the actual Go for it. We take a look at this contract. We're gonna see you folks. We can come up with these numbers last night and The yesterday, I believe you got the 60 38 Okay. Yeah, right. Yeah, I believe so. Maybe it's 37. What was it? 38 yep, and 39 it's the high now the way that I look at this is that You know yesterday you did push, you know, we had some good volume. That's six hundred eighty six thousand contracts Okay, going into 655. So that's telling me that's gonna test that even though it's a penny Santa wants to go up there now. We're gonna sideways move out here today. So it's gonna be interesting then you know I would say that that's only that's only third less than 40 pennies away from where we're at, right? Oh, I know yeah But but my point is is that if you break this this is this if you break this with conviction You can really go okay, you know, okay, but guess what? This is what's stopping us and its tracks right that $5 a day down an oil which is 60 34 Yeah, exactly down to 55 83 right, you know, and that would barely cover your cost on the 11s or the new ones Yeah, you thought you were gonna face some you know, and I'm just there's a seller there Yeah, the seller right there.  How many you want you want to buy? Yeah selling full wood in the market. This is the exact same thing is selling you sell water in the market You deliver to the market guess what you're all set. Yes for sure. So let's see This is the top live that they pull up on Bloomberg about 10 minutes ahead of time. So let's see what they're looking for Something odd's been happening in Cushing, Oklahoma We saw a big rally in WTI spreads this week and the June December spread even moved into backwardation Despite more than 46 million barrels of oil in tanks inventories have been drawing this month, which is counter seasonal given refinery maintenance season Traders are whispering quality issues. Let's see quality issues gain related to how much deliverable WTI is available. It's interesting. Yeah, this is gonna be an important area to watch in the coming weeks So that's saying that yeah, you have the oil, but how much can you actually deliver? The oil that's ready to be yeah, and after the process the next one The quality yes, and the next one speaks to two and that's it's so cool about commodities There is such a fundamental aspect to this, you know where because we spent much of this past week watching the ITC chemical tank fire Oh, yeah, it's all right. I mean amazing and the Reignition and contamination of the Houston ship channel the closure of the ship channel likely affecting refineries I expect to see impact divided between today's report and next week's data That's gonna you know you can't get ships through the channel with the oil, right? It's it's that's that's gonna affect this number now granted There we go, right? Yeah more on the ITC fire from last week There could be a lot of noise in the import export figures to given how many terminals had to shut That may cause a backup of crude in the Gulf Coast where we are expecting roughly double the volumes of what we import Yeah quite a fireman and those chemical fires Not an easy thing to to put out as you see no doubt. Yeah, so we get Six minutes. We'll see those babies going. Let's just check back. I'm curious if we're still sitting right at that $60 mark as we come in Yeah, it's just hanging right there waiting for those numbers. We'll check. Okay. Yeah Welcome back folks down right now is trading up 64 NASDAQ is a flat S&P's up for and crude inventories rose 2.8 million barrels, so let's see what that's doing to the market. You got it and we were looking for of course for decline Yeah, that's the median analyst estimate jumping back to the platform Nonetheless, so it looks like you did have an immediate spike from 10 the 1025 bar to the 1030 where it Gapped lower right and opened at 59 86. So you got a 14 cent gap on like literally the second in between the bars Yeah, but we're right back at $60 just like And of course, you know, you should have we're looking for a decline We now have more like four million more than the estimate in this So you got all that extra oil people should be paying lower prices for the same amount. Yeah supply equals demand, right? economics of the year the curves But nonetheless man oil looking for higher prices 5996 and making any of those trades the last thing you wanted $60 is that your max being total loss of The investment on either side, but we're a minute into the news Yeah, and I would expect we're gonna get a little volatility in both sides of it So there's the breakdown. We see a surplus 2.8 million barrels Median estimate had been a decline of about 2.5 million barrels Cushing was up 541,000 Pad 3 was up 4.5 million barrels gasoline pretty close looking for a decline of 3 million came in at minus 2.8 million Dislits a million off but a decline of two versus a decline of one Still cold out there. So here's part of what we're reading, right? Refinery utilization. Yeah, a big miss They were looking for a plus point five you get a decline of 2.3 And I wonder how we see kind of the analysis of this because you know what we will we saw down here ahead of the news When they were talking about what we're looking for Let's see we're down We'll find it but they were talking about those where refineries may be being closed or even getting the oil to those refineries, etc But it looks like plenty of oil man. Let's check back on oil Okay, there you go. There we go So that five-minute bar that we were looking at got us back up right the high 60 oh for and then we actually finished that I'll close not that bar 59 69 so 30 cents and now we're sitting 59 78 to recap You're gonna do those volatility trades. You're the noon cost you about $30 I believe you had the excuse me the 11 a.m. Cost you $30 the noon was about 40 Yeah, and if you want to go all the way until 230 with the $5 it was gonna be about 54 cents away from 60 bucks that you would need so you need more than 20. That's you know what I mean as in we haven't quite got a move It's pretty wild. That's for a big man. You're on this to 60 doll level man Yeah, you know, that's that's that's a big number and of course what's gonna happen before we know it Is that I guess what you're gonna get back into driving season? So oil should have the wind that's about its back, you know coming into what two months is may right April man Yeah, well April's Monday. So it's almost right. Exactly. It's almost one month. Yeah, you know may 30th In the gasoline market is the beginning of the driving season till basically August 15th or something So so there's some of the analysis out here in terms of the refinery runs We were talking about took a tumble at a time when they have typically started to creep higher after seasonal maintenance So they must get in that maintenance right after the refineries go crazy Thanks to a spate of fires and other upsets the Gulf Coast was especially hit hard with crude demand down 294,000 barrels a day That may have contributed to the 4.6 million barrel increasing crude stocks in the region That's a monster that is Yeah, and that's what so you know refineries aren't running right you got all the crude And you just got to leave it in crude It becomes a crude surplus because you can't get into gasoline. There you go 877 9276 648 we have these dial up 8 now as that gets down 11 S&P's up one and a half come right back That's fine. I was happy with oil before you that's right. So 59 75 Okay, only a quarter move on on quite a miss, but we'll see man. The day is young We'll see stay right there folks. We've got fast market coming up next that of course We get our member of the battles of Chapman Steve Rhodes. They wiped you back this afternoon. Thanks, man. Thanks, man Oh


Okay, great. So the next paper is on anamorphic encryption, private communication against a dictator by Pino Parciano, Duong, Heon Fan and Moti Jung, and Pino will give the talk. Thank you. Thank you for being here. Almost the last session. Okay, so this is anamorphic encryption, it's work with Heon Fan and Moti who is not here. Okay, so let's see how this work. Okay, so privacy is a basic human right. And, okay, it's in the United Nations Declaration of Human Rights. It's very well taken as a basic human rights in most countries. And cryptography, we are proud to have done, you know, been very successful in providing tools for encrypting. So for example, just to mention one, it's the signal protocol and the app which most of us have on the cell phone, which will give us some degree of privacy communication. But we observe in this paper that the success of cryptography in protecting privacy relies on two assumptions that are very, you know, they are quite obvious we take them from granted, but they might be challenged in a dictator in a dictatorship. Okay, so bear with me for two slides. These are quite obvious. First of all, so encryption guarantees privacy of the message only with respect to parties that do not have access to the secret key, obviously. Okay, this is codified in the industry game. And the assumption is that the receiver, the owner of the secret key is able to keep the secret key in a private location. Okay. The second observation with an ensuing assumption is that the cipher text carries the message that was encrypted, not the message that the sender wished to encrypt, obviously. And the assumption is that the sender is free to pick the message to be encrypted. So we have these two assumptions that you can keep your key secret and that you are free to pick the message to encrypt. Okay, so, so why is this the problem is, you know, or most of our results are conditional anyway so maybe, you know, this is a classical theorem from, from, from a textbook instead of saying you know assume existence of one way functions and then you say oh assume existence of one way function and receiver privacy, then there exists a secure symmetric encryption schemes, something like that. So we have to assumption web one way function we just make it explicit ability to hide my key. Okay, the problem is that the two assumption are quite different in nature. The first assumption existence of one way fashion derives from our understanding of nature. And it's something that if true is going to be there and it's enforced by nature and nobody can do anything about this. And if it's false if there are no one function that there are no one way function for anyone. Okay. The second assumption is that is enforced by political power. In the sense it can be changed by law and decrees like, you know, if I became a dictator I could dive a decree and say, Oh, it's illegal for you to hide your secret key from me. And then it could and then in this change in this sense it changes, but not for everybody just for some of us, but not for all, and especially will create an asymmetry between the dictator and the regular citizens. So, so this is a different between law nature like existence of one way function and normative prescriptions. Okay. So, both assumptions are realistic in normal settings I'll elaborate a little bit more on this. And so no wonder since we live in, in good countries in a sense and this, you know, most of cryptography has been developed under this assumption.  This is what you know that's what we think we are and that's on the right that's what we want to achieve even if someone is going to hit us on the on the head with the key with with the with the ranch then we're not going to surrender the key or if we do that will be useless. That's for a civil person also for sender freedom citizens might be invited to send some messages like for example I don't know if you have followed. There was a case which is not clear about a tennis player, which send messages to the president saying that she's fine but it's not clear if that message was was was a real message or was something she was invited to send. Okay. The case is clear for dictators but also in what I call the regular countries or other countries that has been an ongoing thread of activities that tried to regulate limit cripple encryption and this became more or less evident in the mid 90s. With the clipper the clipper chip initiative by the US, and this go under the name of crypto wars. There is this war between mostly law enforcement that you know they fear that encryption will give an advantage to the bad guys, and they want somehow to limit and regulate the use of encryption. And in fact, there have there has been a lot of work in the community. I just mentioned to, you know, the earliest work that I'm aware of it's by Silvio Micali in 92 about fair crypto system. And there is from last Euro Crypt. This work about areas and they try to use cryptographic tools and normative normative prescription to try to, you know, limit the use but under the rule of the judiciary. The problem is that in the dictatorship, there is no independent judiciary system. So there is no one where the police or the dictator should go and get, you know, a war and say, Okay, now you are going to give me your keys. And, and it's not clear that if we put these teams in place, then maybe the political regime will change and then we'll give a very strong tool to the dictator. The concept of crypto wars is also related to kleptography a concept invented by Adam young and multi young. And also there is some a very related stream of war comes a vertical encryption, which actually is tries to address the dual problem that we're trying to address. Okay, so how can we fix this suppose that we want to, to give tools that can be resistant to dictators. Of course, we cannot.  Okay, there is this crypto paper and you know dictator this crypto paper is gives you an encryption scheme which, you know, even if you try to get a ticket key even if you force me, we can get around the first thing the dictator will do is going to make this game illegal. Okay, so rather with the jet we should look at the existing scheme existing schemes and show that these teams as they are, they can be used as they are or modified in an undetectable way can be used to get around these two problems. Indeed existing schemes cannot be disallowed because they've been already deployed and there are some legitimate use, but even if he wants to disallow the schemes, then we'll make the dictator really registered to every Euro Crypt and crypto to check what what we've been doing and then keep a list of what is going to be which is very inconvenient if you're a dictator. At least that's what we hope. So what is our approach. Let's look at the receiver privacy receiver privacy when you get hit on the head. Okay, to surrender your team. So, there are two constraints like the dictators as the secret key, and it can decrypt and read the message, but okay this works in our favor, only messages that are being encrypted with the key that is given to the, to the to the dictator. Our approach is to have to dream of something like a cipher text is actually associated with two keys. And the cipher text carries two messages one with respect to each of the two keys and zero and one. And in a sense, that is no second key. In a sense, that's at least what the dictator thinks that there is no second key. And that's what we can quite easily deny that there is such a key. I'll just give you an example right now. This example also appeared under different name in the literature. Like for example, he's on the work by Bellard Patterson and Rockaway in crypto a few years ago, and it's for the dual problem for subvertible encryption. And it also appeared very recently in the in the in this working in the innovation to the computer science by Horrell Park, right. So on and by Kuntan and I must. Okay, we know. Okay, so just take any encryption scheme. Okay, this is the normal mode. I don't have to go through the bullets because that's what what we have now suppose that Alice wants to send a message, you know, glory to our leader. Okay, but she wants to read just for the sake of this example just she wants also to send. No, that's Bob Bob wants to send one bit to Alice. Okay. So how does he do it. Okay. So Alison Bob share the a seed K for a pseudonym function. So when Bob stands the message glory to our leader, he keeps sampling ciphertext until he gets a ciphertext that evaluates to be the beats that he wants to send under the shared seat. Okay. As you can see this. This is going to work because, you know, he, that's just a regular just think of it as as for example for secret key, or, you know, I don't know whatever you know RSA or AP. And the dictator justice normal communication and even if Alice surrenders the key for the encryption scheme. Then, you know, the dictator will see all glory to our leader.  With Bob Alice could say, you know, what seed there is no seed. Okay, I'm just using a yes I'm just using RSA or AP. Okay, so this is a feasibility in a sense that what we're dreaming of actually actually exist. Yeah, this is a theorem. And of course there are some. There are some restriction as you can imagine like it can be extended to any length you just keep sampling but of course this is going to be exponential the extended time is going to be exponential in the length we call this we call it receiver anamorphic why because you know there is a normal mode and anamorphic mode anamorphic images are those that you know give you different images depending on the angle on which you look at them. Okay, so, so for the dictator it's the normal mode for Alice and Bob there is the anamorphic mode so we call them receiver anamorphic and then will be sender anamorphic to address the second problem the sender freedom in fact these are the our two technical contribution we're going to give a receiver anamorphic for many beats polynomial time. rejection sampling only works for a few beats. And we're going to give standard anamorphic with no shared key remember that in rejection sampling as well in the one that we're going to show next. We're going to have to agree on on the seat. Okay, here instead in standard and more anamorphic. We are going to do, we're going to do this completely with no prior communication. And for this we need some extra property we'll see those. Okay, we take the now or young encryption scheme this is an encryption scheme that provides CCA security CCA one CCA two depending on the strength of the needs and we're not going to this detail. But this is the slide that describes now or young I think that most of us, you know they keep it in mind but that they remain but you know just for to refresh there are two public keys, but there is only one secret key. Okay. And actually this is crucial in the in the proof of security. So if you want to encrypt a message like glory to our leader. So you will do you do you encrypt it with the first public key encrypt it with the second public key, then you produce a proof that the two are consistent, and then you send it upon the crypto, you know upon arrival of the cypher tech Alice checks the proof, and then it decrypts the first one. Alice has no second decryption key. Actually, you know, for example for El Gamal you can sample a public key without having the corresponding secret key but. Okay, so this is the normal mode what is the. I'm sure that now it comes, you know, most of you got it already because what is the anamorphic the anamorphic is the following like, okay, Alice actually keeps both secret keys. Okay. And now, when Bob wants to send a message, he sends on the first secret key, you know, the official security, you know, glory to our leader. And then he sends, you know, fine to our leader, you know, just find our leader for illegal parking maybe that I don't know what they mean. Okay. And the secret, the secret shared information is the simulator trap door. Okay. So, instead of having a Sigma a truly random string, or, you know, a string from the right distribution depending on the underlying needs. So what they do, Alice runs the simulator gets a string which is indistinguishable from what it should be and gets a trap door. Bob shared the trap door that allows Bob to produce a needs a fake needs a cheating needs that the two messages are equal. Okay.  And that's it.  And while Alice has also SK one and the creeps and the creeps the real message. Okay. Let's find the our leader. Okay. Now you can see that. Okay, why does this work. Okay, the properties of needs different flavors of needs that you want to do simulation sun so depending on that, but this implies that anamorphic and normal public is very indistinguishable. Our needs plus in the CPA imply that the cipher text are indistinguishable. So the fact that they are not the same cipher text but they are deep. Of course, this is hidden. And this is what I said, PK one could be generated without associative secret key so Alice could, you know, oh, no, I'm just following the protocol. I'm just, you know, following the wall from the paper, and I have no SK one. Okay. And the other line PK zero PK one Sigma now helps is the trap door is can be proved to be a significant encryption keys or all the proofs are in the paper. The paper is only print and in the proceedings so but I'm not getting into proofs now. Okay, so let's come to the to the final, the sender freedom assumption. Here we assume in this assumption the sender is free to pick the message, which you can you know you can be fought like you have a gun at your head and then you say okay just let the message that everything is fine. Okay, that you're free to move and then you know nobody should worry about that. Okay, so this is a story of Oscar and john Oscar is a political you know position leader. Okay. So at this point, there are, you know, all these opposition leaders being persecuted by the data, the data wants to look good to the, to the world public opinion. So it just goes to Oscar say Oscar, why don't you send a message. I'm fine and in good health. Okay. So what we need to do with the to a forced public key fpk fpk could be you know like the public key over some media outlet, you know, Bloomberg, you know, right or whatever. Oscar wasn't wants also to send a message. Hey, I'm in prison, and he wants to send a message to his friend or to a journalist, not necessarily his friend called john. Okay. And john has, you know, is publicly depicate the public is up there it's well known to everybody it's it's on the on the website, and Oscar and john have not talked beforehand he just is okay. Oh, there is this guy that seems to look good. Okay. And john so Oscar computes. Oscar. Oscar does the following. He computes some special coin tosses are stars. Such that the cyber tech city encrypts a message and zero that's the dictator picked message, say, oh, I'm fine and in good health, and he sent to the force publicly so that you know the official media outlet gets this message, our star. And it also holds that if john tries to decrypt the same cypher text but with this secret key, then he gets M one. So this is again an amorphic depending on under which angle you look at the cypher text. And you know, depending on which secret key you're going to use to decrypt, you get two different messages, but it's one cypher text. And of course john knows that his key might be used to. Some messages from opposition leaders, and then it decrypts also messages that he sees broadcast on the network. Okay. And I want to stress that there is no prior shared knowledge between Oscar and john. Okay, they don't tell you know this is different from now or young and rejection sampling. Okay, can we achieve this.  Okay, so before you know giving you the result. So I want to just elaborate about send an amorphic and then I want encryption. First of all, if you remember the denial encryption from 97 that they can add the credit at all paper that that applies to the same public key. Okay, and, and this is it's impossible for standard encryption. Okay, which contradicts one of our main objectives. So send an amorphic can be used to provide some form of the liability, but this is in a different context. Now, the context is messages being broadcast on the network while the niobal encryption was for point to point communication, which in a sense, justifies the assumption of being denied with the same public key. Okay. So we have certain conditions for send an amorphic with no shared key. Okay, so we have these three conditions which are quite, quite reasonable. First of all, we have this property common randomness property like for any plain text and any other public key pk prime or refer to three is the valid cipher text also under pk prime. The second properties message recovery from randomness that if I give you cipher text and the randomness that has been used then you can recover the message and the third is equal distribution of plain text, meaning that even see for randomly generated SK, the probability that see is an encryption of zero and encryption of one as more or less the same. Okay. So under this, we prove that these three conditions are sufficient for what we want to achieve. And then we go on and prove but details are in the paper but and I'm not going to discuss this that two very well known encryption schemes based on LWE reggae from 205 and the Gentry piker and Vinod from 208. They satisfy this three condition, and that they can be used as standard an amorphic encryption schemes. Okay. I'm now to the last slide and. Okay, so I'm doing pretty well on time, I guess, yep. We started a little bit earlier but. Okay, so these are the conclusion so we introduced two new concepts receiver anamorphic and sender anamorphic so the receiver anamorphic is useful in in settings where the receiver. All the communication is under the dictator's control, while the sender anamorphic is when at the center of the message is under the dictator's control. Okay. We show implementations of these two concepts with existing crypto system from the literature. Okay, so that we, you know, I don't know if anybody's using in our union right now but you know, in principle, you could use it. And, and that's the, I think that we think the most important point of our of our work is that we give technical evidence that this the futility the stupidity of the crypto wars, like encryption is the technology that is there. And there is no point in trying to regulate to make it weaker or to have a control state control on that like encryption is saying is there and then if you try to do something there is something. You know, we have a way to go around whatever the dictator or the good government does for your own good. And, and if the dictator really wants to pursue this, at least he'd like to register to our crypto and Euro crypto and read all the proceeding is it should get a PhD in crypto and okay, and that could be also a good, a good result. How I saw how how this is going to affect policy law, and that are societal aspects of course this is beyond, you know, our expertise it's not in our ballpark this is not the right forum, but it's just a technical contribution like, you know, none of the three of us is is a social scientist that I know. And so, of course, but I think that it's important to, to say that you know encryption is here to stay. It's like, you know, when fast cars were introduced like, I don't know if back then, you know, the police complain oh now they have fast cars.  And that's in a sense what they're trying to do with encryption. Okay. Also, the last bullet is that an amorphic encryption is not a bizarre phenomenon like we have seen it in some very well known and studied crypto system there is nothing pathological in our constructions. And, you know, there is more to come there is work in progress, and we would like to see, you know, more non crypto system to be proved to be an amorphic. And just to complete the whole program of showing the futility of the crypto wars. And this is what I wanted to say, thank you for your attention. Thank you for being here in the last session. Questions. Maybe you can use this one. Thanks for the great talk. So, on the technical level it seems that to achieve receiver anamorphic encryption, or even the sender anamorphic encryption, you need to share some information between the parties so in particular, for the receiver case you need to share the trap door for the music. And for the sender you need to share the randomness right now. No, no, no. But at least for the receiver you need to share the trap door. So, how do you assume that to do you assume like an underlying anamorphic key exchange or a key transport protocol that does it. Okay, that's a good question. Okay, first of all, I want to make sure that maybe I was not. I didn't say clearly here. No, it's not this one. Okay, so. I cannot find the job. So for sender anamorphic there is no shared communication like the sender by himself by himself picks a special R star, but there is no way there is no need to agree on the outside beforehand with with with the receiver. For how do you get how do you like for receiver how do you agree on on the seed of the pseudo random function or on on the trap door of the random. Okay, so, so we think the setting the 20 minus that this is a group of opposition leaders, opposition activists, and that they get together at one point, and they just share the the, you know, this information. I must say that the paper of Horrell et al. That's exactly what you want to what you describe it in the sense that they have some sort of stegan, stegan graphic key exchange. Okay, about, you know, you have to see maybe different settings things that different ways but then you first of all you have to start a secret sharing a key sharing protocol. Which might attract some stuff, you know, some suspicion from the dictator, and also it's very low rate, the so they take some time to agree to agree on the key. And suppose our so we have this concept in the paper about latency, how our sense zero latency the moment you have the two keys that you can start. But you know, these are very good questions. Thank you. Thanks for the interesting talk. My question is about the non interactive zero knowledge proof that the dictator verifies. So, is it only specific kind of non interactive zero knowledge proof techniques can be used in anonymity encryption schemes or any schemes. No, any needs. Then a bit. Okay, of course you should get you know if you want to say to you want simulation soundness, you know, but any needs will work. It's genetic in that respect, any needs for which there is a simulator. Okay, so it has to be zero knowledge. Thank you. Thank you. You know, great. I love this name. I'm not sure if I love this name exactly it's very catchy it's kind of cool. I'm not sure if you're aware in the mid 90s there was another paper called plausible deniability which took the same tack, which is kind of looking at a crypto system and finding ways to use it in deniable method, kind of like CDN O post dated CDN O. The idea was to say let's use this in a way that people are not expecting it to be used. So there's there's this one aspect of this it was about the wheat about the time that wheat and chaff came out as published in Progercript I'm wondering what the differences there might be it also is using sort of a trap door thing. Yeah. And the other half of it to is the other question which is maybe a more uncomfortable question, which is how do these things really resist sort of the screwdriver attack, which is the dictator just comes and says what is your alternative key what is your alternative key what is your alternative key and applies a screwdriver every single time until you actually give it up. Okay. Okay. Yeah. Okay. You know, two good points about the second one. Yeah, but if the dictators does that he could really, you know, very well get into someone who is innocent and doesn't have a key. So, and he's going to create a client, you know, terror in the population, which is something that he might enjoy, by the way. So, so I'm not saying that, you know, this is going to solve all the problems but at least there is reasonable doubt that, you know, I'm just using as there is no speed. Okay, leave me alone so but that's about the first time maybe we should talk because maybe we missed we know there are several references and we do compile so maybe we take it offline with take it off side and we discuss it. Thanks. Okay, I got a screwdriver. Okay, okay. Thanks so much for this talk. It's really, really interesting. One thing that occurred to me well sing to your talk is that dictators do show up at Euro Crypt and crypto. We know, with a lot of certainty there's records from the NSA during the Snowden leaks that they come to Euro Crypt and we're like hey they're not working at the interesting. Don't worry about it keep going. And certainly encompassing the US there's always a DoD person who shows up in the back of the room. And so in light of that I'm wondering to what extent you've been able to characterize the necessary conditions for these kinds of communication protocols anamorphic encryption like do we know that if we don't use anything if the government says no LWE ever we're done with LWE. Can we not do anamorphic encryption? Is there some kind of like minimum entropy in a channel that we need similar to like steganographic techniques or is that kind of like an open question that's that's we want to look at next? Yeah, no, no, right. Terrific questions. These are all questions for next work and these are great. I don't know. I'm looking at back rows. Maybe they don't come to Europe. I don't know. It's hard to get a visa or something. Okay, okay, okay, so we'll see in 15 years when we release that. Thank you, thank you. So have a quick question. So what is the connection to steganography? Steganography also says that you can take basically any randomized encryption and by playing with the randomness you can encode arbitrary messages in the ciphertext. So what is the connection? Yeah, in a sense like that, if the, yeah, steganography, the dictator could get in and say, okay, you're using steganography show me this and also with steganography on the receiver side, it could have, you know, you could get the key and the sender on the sender or pick we have this property where you can send it to any other secret public key, which for which you had to know why steganography you cannot do that like steganography is point to point. So there are some differences which but I agree it's it's very common. They're very close as concept but you know our emphasis on is on existing scheme is not on designing new schemes. So we are anyway out of time. So this is the end of the session. Let's thank both the speakers again.


Fervour for dharma is actually a fervour longing, a yearning for the right way to live for yourself. There's no one right way for everyone. That is why you say Hindu dharma because it isn't a religion, it's a huge body of different ways and means of living according to each one's choice. So your fervour for dharma is actually your fervour for the right way to live for yourself. In other words, a way of living which keeps the suffering low and raises the joyousness of your existence.


All right, good morning, everyone. Thanks for attending. So I'm Eric Malm. I'm the product manager for the Diego team, one of the core projects in the Cloud Foundry application runtime. And today I'd like to give you an update on some of the things we've been working on since the past North American Summit. So first, some administrative business. If there's a fire, remain calm, exit according to the signs can be an outside. All right, so first, let me give you a brief introduction to what Diego is, in case you haven't heard of it before. So Diego is the container runtime that's tailor made for the CF application runtime. So it's actually a fairly old project at this point. We initially started development to replace the previous system, the DEAs, back in January of 2014. And about a year and a half later, we reached a point of parity and stability that we said was generally available for use. About a year after that, we demonstrated that we could run a quarter million containers in a full CF environment, stably. And so at that point, that was our milestone for declaring 1.0 on the release. And that started the deprecation clock on the DEAs, which removed six months later. And then lately, we had another major version release a couple of months ago, kind of clear out some of the, and simplify some of the configuration in the release, while still preserving the ability to upgrade across major releases, as long as you're hitting adjacent ones. So today, I'd like to give you a brief overview of how the Diego components fit into the Cloud Foundry application runtime. And then a few selected updates about what we've been doing. So one thing I'd like to tell you about is how we've been improving the stability of performing active health checks against application containers. So we've seen a few issues arise there. And then switching gears a little bit to tell you about some security improvements that we've been making around some instance-specific credentials that we're supplying to containers, and how we're improving the platform on top of that. Finally, if you're responsible for operating Cloud Foundry, you may be interested in some of the improvements we've made to our operator tooling that lets you inspect the internals of the system more conveniently. And then finally, I'll tell you a little bit about some of the next steps that we're thinking about in the months ahead. So first, if you've been using Cloud Foundry, then you're likely more familiar with more external facing components, such as the Cloud Controller or the Go routers that handle HTTP traffic. And you've almost certainly experienced the magic of running CF push and very quickly observing your build pack or your doctor image or now even your Windows applications running on the cloud. So let me tell you a little bit about what's happening under the hood here to get those application instances running. All of these instances are running as containers inside of Cloud Foundry's container engine, which we call Garden. And Garden is great at its job, which is to execute containers, create them and run processes in them. But it's also very intentionally a local system. It knows how to run containers on its local host. But it doesn't know about the rest of the distributed system that constitutes Cloud Foundry. And that's where Diego comes in. So Diego was responsible for organizing placement and execution of those containers across dozens or hundreds or thousands of container hosts and ensuring that they're all doing the right thing and they're all running according to the desired state that all the application developers have pushed. In order to do that, the core of Diego has some dependencies. In particular, it relies on a consistent data store to coordinate a lot of this activity. And nowadays, that's a SQL database. So MySQL or Postgres. And then the components themselves also need some degree of coordination so that they can be behaving correctly amongst themselves. In the past, we've used console for that. And we've been introducing our own replacement for that because of some issues we've seen around using console at Bosch together. And then finally, if you're using Diego release, it includes some ancillary capabilities, most notably the system that enables SSH access into application containers. So I'd like to do a little bit more of a deeper dive into how these components are arranged in a typical CF deployment, such as one that you might get from the CF deployment repository on GitHub. So if you've been using that to deploy Cloud Foundry, you're most likely familiar with Diego from the Diego cell instances that that deploys. And as you might guess, that's where Garden is running on each host in order to do its job of creating containers and running application processes in them. But as I mentioned, Garden is this local system. And so Diego starts to come into the picture here to connect it to the rest of the Cloud Foundry architecture. So the first core component of Diego that lives on the cells is what we call the cell rep or representative. And this is responsible for registering the presence of the cell to the rest of the distributed Cloud Foundry system for managing that local Garden to do its job of making containers. It also does some accounting for the memory and disk allocations that it's making for those containers. And then finally, it's responsible for downloading some of the assets like the droplet and build packs that go into those containers to do various types of tasks. And so it caches some of those depending on the data that comes in. But the reps themselves are not receiving that work directly. And that's where the other core components of Diego come in. So the next instance group that you will likely have seen from CIF deployment is called the Diego API. And that's where the BBS, the next main Diego component, lives. And that's responsible for providing the public API to the rest of the Cloud Foundry subsystems so that they can submit work and inspect how it's going after they've submitted it. And the BBS also understands the particular types of work that Diego is capable of running, namely long-running processes or LRPs and one-off tasks. And it enforces the various lifecycle rules and state transitions for those as it manages them across the system. The one thing that the BBS doesn't do, though, is make direct decisions about where that work gets placed. And instead it delegates that to the third core Diego service, which is the auctioneer. Nowadays in a CIF deployment-based deployment, it's a little redundant, that's living on a VM, or instance group, called the scheduler. And so that auctioneer is responsible for receiving work to be placed from the BBS, communicating with all the cells that it can find, and deciding optimal placement based on that up-to-date set of criteria. Lastly, I mentioned this locket component that we've been introducing. This is responsible for coordinating many of the distributed locks and the cell presences that the rest of the control plane needs to find the active instances of these services. So in particular, you'll notice on this diagram that we have many, many instances of each one of these instance groups. But for the BBS and the auctioneer, only one of them is active at a time. And so locket helps coordinate that activity. Finally, the BBS has one other crucial responsibility in the system. It's also responsible periodically for assessing both the desired state that clients such as Cloud Controller have expressed and the actual state coming from all of the Diego cells in the deployment and reconciling any differences. So if there are extra instances that shouldn't be running anymore, it tries to stop them. And if they're missing ones, it resubmits them for placement to get them running again. Anyway, so that's an overview of the core components of Diego and how they help manage this responsibility inside of the Cloud Foundry application runtime. So I'd like to change gears now a little bit and give you some information about some of the updates we've been making over the past year. And one of these is to do with how Diego on the Diego cells performs active health checking of application instances. So our previous way to express this through the BBS API has been through something called the monitor action. This is a fairly generic action to perform periodically to assess the health of an individual app instance. So this could involve running a binary that does a TCP port check or an HTTP request against the application. But in general, it's fairly broad. You could basically run anything, any other kind of process inside of there. But through the Cloud Controller, we've only really expressed these kind of network-based health checks. So just to illustrate, let's say we've got the Diego rep running on a VM represented with our little logo here, and we'll look at what happens over time as it starts to run an application instance. So let's say it gets assigned an instance of a Ruby build pack-based app to run. So it first talks to Garden and creates a container for it. And then it starts to invoke the application start command inside of that container. So of course, that process is not going to be initially ready to receive traffic. It's going to have some warm-up period of at least a few seconds before it starts listening on its support and is capable of servicing requests. So let's say that it eventually becomes healthy, but not immediately. Here's how Diego detects that to know when to start sending traffic to it, to register it with the route and control plane. So a couple of seconds after it invokes that process, it begins this monitoring process. And it does that by invoking whatever was specified in this monitor action inside of the container as a separate process. So that process itself is going to have some amount of warm-up time. It's going to need to potentially load files from disk into memory to get them executing. And at some point, it's ready to go. And it does its check against the application instance. And it's not ready yet, so it fails. So the process then winds down and reports that through the Garden API back to the cell rep. So at that point, the Diego rep knows that this application instance is not yet ready to receive traffic, but it hasn't been so long that it's ready to declare it failed yet. So it just waits another couple seconds, and it tries again. And this time, it catches the application instance right after it started listening on its support. So it says, great, this instance is ready to receive traffic. And it goes and emits route registrations, updates the BBS with the networking information that applies to this particular instance so it can start receiving traffic. But that's not the end of the story in terms of how the cell continues to monitor this process. So on a less frequent time scale now, it continues to invoke that same monitor action to probe the correct behavior of this application. So 30 seconds later, it's going to run another one of these health checks. Everything's working fine at that point. So it reports that that instance is still healthy. It keeps it registered with the control plane. Well, we observed that as convenient as this process was, especially to express via the Diego APIs, it did occasionally suffer from some problems, especially when there was unexpected resource contention on the cell. So if the disk's really slowed down, or CPU really slowed down for some reason, then you could end up in a scenario like the following. So 30 seconds later, the rep invokes that monitor action again inside the container. But now, because of that resource contention, things are taking a lot longer to start up. Maybe it's taking garden a longer amount of time to get that process actually running in the containerized context, because as you may have seen from some of the garden talks, that's actually a complicated process. Or maybe it's just taking longer for that process even to start inside of the container. So in this case, maybe that health check is still able to successfully evaluate that process inside the container, but it's really taking a much longer period of time to finish that process. And the Diego rep is actually told not to wait forever to perform this monitor action. And at some point, it's going to decide, this has taken too long. I haven't heard from it. Something has probably gone wrong. And it's going to mark the instances being failed. So even though eventually this process returns to the garden API and says, I succeeded, exit code 0, then the Diego cell is going to decide this instance is not functional anymore. And it's going to stop it and report that as a crash through the control plane and get it rescheduled elsewhere. So we've seen this occasionally lead to cases when instances are actually healthy, but the health check is failing such that we think it isn't anymore. And in the worst case scenario, if you have a lot of contention on your infrastructure, then this can unfortunately lead to some cascading failures that are difficult to arrest. So we thought, OK, we really want to improve this to improve the resilience of the platform. So here's what we settled on. We actually introduced a new API on the desired LRP specification called a check definition. And it provides a much more narrowly scoped interface to define the kinds of health checks that we found important in Cloud Foundry. And we have these TCP port checks or HTTP requests. And so Diego is now free to reimplement those as a longer running health check running inside the container that takes much less system overhead to orchestrate and is much less sensitive to things like resource contention on the cell. So let's look at the same scenario with a long running health check performing that. So again, we have the Diego cell and it's being assigned an instance of this build pack application to run. So again, it creates the container and starts the process, which is eventually going to become healthy. So in its health check assessment of this process, it starts out just as before, where a couple of seconds after launching the process, it starts this health check. And that initially finds that this process is not healthy. But instead of exiting and returning right back through the garden API to the Diego cell, it instead just keeps running. It knows that there is a certain timeout for the startup of this instance. And the rep knows that too. So it's just going to hang out there. And a couple of seconds later, check again. And at this point, the application is healthy, just like it was with the short running health checks. So that process exits and reports back to the cell that everything is functional. It's good to go. And then the same long running procedure happens for the ongoing health check to assess the liveness of this container. So again, the Diego cell invokes this health check in a long running mode. And it performs a health check. Everything succeeds. So it just waits another 30 seconds to do another health check inside the container. And that all works. So let's also see how this works when it's detecting a failure of the application instance. Let's say that at some future point in time, it actually does go bad and closes its port or stops accepting HTTP requests. So that health check on its next period of probing is going to detect that. And that point is going to exit with a non-zero exit code. And that's the signal for Diego to know that this health check has actually failed inside the container and to rightfully kill this malfunctioning application instance and get it rescheduled elsewhere. So we've definitely seen this reduce the amount of system overhead that is required for the system activity to monitor all the application instances, especially as your container densities on cells go up. We actually just realized on the Diego team that we've considered this stable for a few months now. We actually needed a little bit of help from Garden to correctly arrange the resource limits on these health checks. And we just had forgotten about declaring it no longer experimental and stable. So hopefully next week sometime this will become just the default deployment option inside of CF deployment to run this way. But you can easily opt into it now with an ops file. OK, moving on a little bit, I'd like to tell you about some of the security primitives that we've been incorporating into the platform and that we've been finding really useful to build on for other system enhancements. And so we've been calling these instance identity credentials because they're a short-lived, per instance, specific set of credentials that we issue to every container running on the platform. So to illustrate, let's get another Diego cell up on the screen here and it's going to start running an instance of an application here. And associated to that application container are several different unique identifiers. So especially if you're using container networking, that container has an IP address that's unique across the deployment. If you're not, if you're still using the Garden built in networking, it'll just be local to the host. But container networking is now the default in CF deployment as well. So this is now typical. And then there's also an application GUID associated with this container that's associated to the identifier that Cloud Controller uses to track this application. And then finally, each instance of this application has its own unique identifier that's also the same as the container handle. It's the host name inside of the container. So these are all identifiers for this unit of work that have different meanings in different contexts. So what the Diego cell does is it encodes those identifiers into a certificate and key pair that it then supplies inside the container. So application processes can make use of it to identify themselves as a particular unit of work on the platform. And it does that before it even invokes the application start command so that it's all ready to go when your Ruby or your Java process starts up. It can just find them in a location that's determined by environment variables. So let's take a look at the contents of the certificate and see how it's encoding that information to make use of. So because this is an X7-9 certificate, of course it has a subject. And that's where we put some of these logical identifiers for this unit of work. So that application comes in as an organizational unit in that subject identifier. And the instance identifier is present as its common name, which we thought made no sense because it matches the host name inside of the container. And then similarly, we have that information present as subject alternative names inside the certificate. So that's a great place to put that specific IP address for the container on the network, as well as to repeat the host name, that instance, GUID, as a DNS SAN. And then finally, these certificates are deliberately very short-lived, by default, only a day. So we'll make one when the container is first created, but it's only valid for a day after that. So if something happens to compromise that application instance, then on a relatively short time scale, that certificate is no longer valid for anything. And this is also something that operators can configure. In the Bosch release, you can turn it down to a minimum of one hour, so that those are rotating very quickly. And of course, there's a unique serial number in the certificate to identify it. Okay, well, you may be concerned what happens when that certificate expires. It's only valid for a day, or maybe only an hour. So the rep knows that though, knows when it issued it, and it knows that validity period. So before the previous one expires, it creates a new certificate with the same identifying information, but a different overlapping validity period. And it moves that into the container over place of the existing files. So if you're an application process, you can either pull that location periodically and pick up the new certificates, or you can even set up a file system watch on those locations and receive a notification through that watch that these files have changed. So this is, I think, a really interesting security primitive on its own, but it's also allowed us to do some increasingly sophisticated improvements to how we're running application instances and routing traffic to them. I think the most exciting of those that we've developed is something that we're calling route integrity, and it's making use of Envoy, which is one of the new class of these very versatile, dynamically configurable network proxies that are becoming increasingly popular to coordinate things like microservices. So let's see how this works on a Diego cell, and because we're gonna be talking about routing, well, let's also get a go router into the picture here. So we can send some HTTP traffic to the application instance. So as before, the Diego cell is gonna start running an instance of an application here, and it's going to instruct that application to listen on a particular port, conventionally AD80, although there are ways to configure that through the CCAPI. So in order to get network traffic into this application process listening on this port, the Diego cell through garden allocates an external port on the host that's going to direct traffic into the container on that particular port. So now when this application is ready to receive traffic, the Diego cell is responsible for registering it with the routing control plane, which it does as follows. It knows its own IP address, so it takes that with the external port and tells that to the go routers. So let's say that in this case, this is an application that's mapped to a route for example.com. So eventually the go router is going to receive a route registration that says, if you want to talk to example.com, then talk to this particular external IP address and this port. So then when it fields a request for that domain, it connects to that IP address and port on the cell and then the traffic is forwarded into the application transparently, so it can handle that. So this has worked great. This has been the route registration and routing model on Cloud Foundry for many years, but it does suffer from a few deficiencies. In particular, we've been very diligent on Cloud Foundry about telling applications only to listen on plain HTTP. Don't handle any of the TLS stuff yourself for secure communication. If you want that to happen, rely on the go router or load balancers in front of it to terminate TLS. And that of course means that the go router to container link is always in this model plain HTTP, which some people have been concerned about as a security risk. And in the worst case scenario, it does mean that if the go router doesn't receive an update to its set of registrations, but the containers are still moving underneath it, it could eventually end up misrouting a request to a different container on the platform. And to defend against that, the policy of the go routers has been to if they haven't received an update about a particular route within two minutes, they'll drop it out of the routing table. They'll prefer to lose availability instead of losing consistency in terms of what they're routing to. So we said, well, this is not an ideal situation because if there's some sort of network outage in the control plane, we don't want that to affect the data plane, how messages are getting to applications. And we figured out that with these instance identity certificates and this new breed of proxy, we could resolve that as follows. So in this model, when the cell is opted into this configuration, it's going to run this Envoy proxy inside the container as a separate process that it knows how to manage. And it's going to configure it dynamically as follows. It'll tell it to start listening on a separate port from that application instance. And on that port, it's going to terminate TLS using those instance credentials. And once it does that, it forwards the traffic to the application port itself. So now the Diego cell, once it's determined that that's all up and running, knows that it's going to allocate a separate port on the host to be directed to the port that that Envoy proxy is listening on. And when it registers this instance to the Go Router, it instead includes an alternate registration with that port and its external IP address. But it has a couple other pieces of metadata there to allow the Go Routers to do the right thing. So it first tells it that this is a TLS route instead of a plain HTTP one as has been the default. And it includes the specific identifier that's baked into that instance identity certificate. So then when the Go Router gets a request for example.com, it prefers connecting to that TLS capable port over TLS. And it starts the handshake and at that point, it verifies that the subject name that's coming in that host certificate matches the identifier of the instance that it was told about. And in this case that works. So it finishes the handshake successfully and then sends the request, which is then transparently proxied to the application. So the application behavior doesn't need to change at all and we're just using Envoy to terminate TLS inside of the application container and proxied the traffic. Envoy's dynamic configuration is also great here because when we rotate the credentials, then we just dynamically reconfigure Envoy with the new TLS context to terminate. So it's all seamless, existing connections, continue transmitting data until they're closed and new connections get the new set of credentials for their handshakes. All right, so this is again an optional feature inside of CF deployment at the moment. You can use an ops file to opt into it. We're also doing a little bit of fine tuning in terms of how we account for the memory usage of these Envoy proxies, because of course that's not for free. And so we're continuing to make that more sophisticated. But if you're willing to give it a little bit of extra room to allocate memory, then this can be a great way to improve the security and the resilience of your routing tier inside of your CF deployments. Finally, I'd like to give you some updates about what we've been doing with some of our operator tooling. In particular, we have a tool that we call CF dot or the CF Diego operator toolkit, which we kind of think of as a command line tool for the Diego APIs. Most of the APIs are binary encoded with protobufs, so they're not very friendly for use with curl. And so instead, CF dot has a set of commands that are intended to interact with those APIs and translate inputs and outputs into streams of JSON. So in particular, you get a stream of JSON objects on standard out, which is great for piping into commands like JQ for further processing, or even into your line-oriented UNIX utilities to do some ad hoc data analysis about your deployment. In particular, we even have a Bosch job that compiles CF dot and deploys it with JQ and even puts them on the path for you. So you can just drop into one of the Diego instances in your deployment and use this tooling to inspect very quickly. So when I talked about this at some at last time, I think we had just reached parity with all of the BBS APIs in terms of having CF dot commands for those. And since then, we've added one that allows you to get a running stream of all of the events about tasks that are happening in your environment. So if you, you may have been using the corresponding LRP events command to monitor activity about your desired and actual LRPs, your app instances, and this lets you do the same kind of thing for tasks. We also added commands to interact with API that lock it presents. So if you want to inspect locks and cell presences or manipulate them, then you can do that using CF dot. And then finally, we've added some commands that let you inspect the state of individual cells or even all the cells in the deployment.  So I'd like to give you a couple examples of how you can use these new commands to do some ad hoc querying in your environment. So let's say you wanna get a stream of how task IDs are getting assigned to cells as they start running. Well you can take that CF dot task events command, pipe it into JQ and look for the particular criteria that indicate that that task has started running on a particular cell. And then just report out the task identifier and the cell ID. So maybe you start this running and you run a staging task on Cloud Foundry and so you'll see this line of output come out saying this task ID was assigned to this cell. And then maybe a couple of minutes later, you run an application task and you see that task eventually get assigned to a cell. Likewise, if you wanna get a snapshot of just the total amount of memory that's available across your cells at that point in time, this is emitted via component metrics but you might not have aggregation of those hooked up or you might want an up-to-date snapshot across the entire deployment. Well that's where the cell states command comes in handy. You can just use it to sum up the available memory that all the cells are advertising. So I was running this in one of our testing environments which has I think a total of three cells. So it came back with about 74 gigs of available memory at that point in time. All right, so lastly I'd like to tell you about some of the things that we're considering working on in the next few months. If you were at the keynote on Thursday, you likely saw Zach Robinson's presentation about how we're thinking about doing rolling app updates. And we've been considering this for a while and I think we finally have the right approach in terms of understanding what the developer experience for that is going to be like and using that to drive the internal system improvements. So we're very much looking forward to collaborating with the CAPI team and especially the routing team on coordinating that so that it's a safe and reliable rolling update mechanism that keeps your application sufficiently routable during the update. Also these envoys that we've put inside the containers are now very tantalizing in terms of other capabilities. We're kind of just scratching on the surface about what we could do with them. And the container networking even now is working on a track of work to explore how to transparently proxy container to container traffic through them to start taking advantage of some client side load balancing features that Envoy provides. We also are always looking for areas to improve how the cells are managing their memory and disk capacity and how they're able to put CPU limits on individual app instances. I think we've even seen some increased interest on the mailing list in terms of controlling that or getting better telemetry and understanding about that. And so we definitely want to hear what's important from you the community in terms of developer and operator controls over that. Because it's been a fairly flexible model and that can occasionally cause some problems for application performance. Finally, along the lines of improving reliability and stability in the platform, I think as a community we've been thinking more about how we can be doing more focused monitoring of the availability of CF installations. And so I'm very interested in thinking about how we can make that even more informative for operators as they are responsible for operating subsystems like Diego inside of a CF deployment. And so we'd like to use that also as raw data both for the development teams and for operators about what features to enable, where to improve reliability. And along the lines were of course, always very interested in improving the general stability and security of the platform. So when any kind of security issues arise or if there's a severe stability issue, that's a top priority for us. So I think we're about out of time but maybe we could field a question or two if there are any. Yeah. Yeah, so the question is about Spiffy as an emerging standard for metadata and app certificates. Yeah, I think we're very open. We don't have a current plan to do that, but I know especially some of the people that are involved with identity management on the platform as a whole. So like the UAA team, they have a lot of ideas that are coming out of the activity around that kind of identity management on the platform. So as we begin to see that standard emerge in the community, we'd be very interested in integrating with it to provide a potentially more federated model for identity across cloud foundries, Kubernetes, anything else that's adopting Spiffy as a standard. Yeah. Oh, right, so the question is, we have these instance identity certificates. How would you integrate them with some external service? So at this point, those certificates are all derived from a root CA that the platform knows about. And so the Diego cells, they get their own certificate authority to issue those certificates. So it would merely be a matter of getting access to the CA certificate for that root authority and having your external service be able to trust it. So if you are operating in a Bosch context, you're likely to have access to that as one of the variables that goes into the Bosch manifest. But if there are other ways that we can more conveniently expose it, maybe through the V2 Info endpoint on Cloud Control or something, so that some other service could discover the platform and decide how to trust application identities. That'd be very interesting. And I think a relatively straightforward capability to build out. But we'd also certainly wanna understand the acceptable workflows because we realize that there's a sensitivity to ensuring that you have the correct trust bootstrapping model for that. So we wanna make sure that you're not getting a bogus certificate and then somehow accidentally trusting bad traffic to those services. Oh, a question is about can we run a more generic command as part of the health check? So I think that's a potential capability. We wouldn't have a current plan to do that, but if it's something that we could figure out how to express appropriately to developers through the CC API, it'd be straightforward to extend that existing definition to accept that as a type of health check. And again, we'd be able to arrange it as this kind of long running implementation inside of the container to ideally reduce the amount of resource usage required for that. Yeah, one more question. Hey, Tim. Yeah, so question is about the actual resource usage for these envoy proxies. So we did some initial benchmarking of their memory footprint in test environments. And we found when they were quiescent, they generally, we were pretty safe to assume they were taking about five or six megs of memory as their footprint. When they handle traffic though, that does increase their memory footprint. And at least in the short term, it looks like it remains fairly stable and it might be relatively proportional to the number of connections that it's handling. So we actually have a story ongoing right now on the team to do more detailed benchmarking of that memory consumption so that operators can start accounting for it appropriately. As part of enabling that configuration on the cells, we do let you add an additional static amount of memory allocation to those containers just to give envoy that additional amount of head space that it uses. But there's a fairly static amount. And so if we can get a better understanding of the dynamic behavior of the proxy, then hopefully we can do something more sophisticated there. Because we certainly don't want to make sure that this is a stable option for app instances and we don't want to be um-killing everything all over the place just because the envoy proxies are running into the walls of the container. All right, I think that's all we have time for. I'm happy to handle questions after this or at Diego office hours later today. So thanks very much for attending and enjoy the rest of the summit.