Hello everyone, welcome back to a new session in dentistry and more today's topic is Jinjeva So this video covers the Jinjeva, its parts, its fibers, various functions in detail. So let's see the details of Jinjeva. So as per definition, Jinjeva, it is a part of oral mucosa that covers the alveolar process of jaws and surrounds the neck of the teeth. So as we all know, it is the covering of alveolar bones and surrounds the neck of the teeth. It has got basically two parts, one is marginal Jinjeva and attached Jinjeva. Marginal Jinjeva is a free Jinjeva which is not attached to the teeth. We can see just around the teeth which is forming a small groove or small sulcus around the teeth, that is marginal Jinjeva and it is also known as free Jinjeva because it is not attached, it is free to move or it is flexible in nature. So that is marginal Jinjeva and attached Jinjeva which is attached to the underlying bone. So it is not movable type, it is firmly attached to the underlying alveolar bone and this attached Jinjeva and marginal Jinjeva which is separated by a groove known as free Jinjeva groove. So this is the marginal Jinjeva, this blue color and the red color is attached Jinjeva which is attached to the bone and this is alveolar mucosa. So marginal Jinjeva basically has two parts, that is Jinjeva sulcus and intertental Jinjeva. So this is a Jinjeva sulcus you can see, this is a sulcus between the Jinjeva and teeth. So it is a V shaped crevice which is 1.8 mm basic depth that is 0 to 6 mm in range which has got crevicular fluid or GCF and the probing depth is usually 2 to 3 mm. So this is a Jinjeva and alveolar bone, so this is alveolar bone. So we have attached Jinjeva from here to here, this is alveolar mucosa, the same picture I am showing here, this is a frontal view, this is a side view. So alveolar mucosa attached Jinjeva. So we have free Jinjeva, this is a Jinjeva sulcus or crevicular area and it is separated by free Jinjeva groove or the marginal Jinjeva groove. From here to here it is attached Jinjeva which is firmly attached to the bone and from that to lower part of alveolar mucosa. So next we have intertental Jinjeva, so that is between the two teeth, okupai Jinjeva embrasure which is site of initializations which is pyramidal anterior region and flattened in posterior region which is basically scallop and presence of intertental call. So there will be a valley space between the anterior posterior that is a front and back region, there will be a valley space or a shallow space which is known as call and marginal Jinjeva which is a collar like terminal edges which is free to move which is 1.5 to 2 mm wide. This is marginal Jinjeva and which is a sluice way in mastication and forming sulcus between tooth and Jinjeva, ok. So this is a sulcus which is formed by marginal Jinjeva and tooth whereas the attached Jinjeva which is a functional mucosa which is very firm, resilient and tightly bound to alveolar mucosa which is spale and pink which is stippled. Stippling is the alternate protrusions seen on the Jinjeva surface which is giving it an orange peel appearances. So the epithelium and connective tissue interdigitation gives that particular stipple appearances. Stippling is a good sign for Jinjeva and if the stippling is absent there will be some pathology involved. So in attached Jinjeva the maxillary incisor region is ranging between 3.5 to 4.5 whereas in molar it is 1.9 mm. In mandibular region it is 3.3 to 3.9 and in molar mandibular 1.8 mm. So what are the clinical huges? The basic color is coral pink color. Coral pink means the coral reefs. The pink color we have various shades of pink. The pink color which is seen in the coral reefs, the seaside coral reefs that's why it's got that peculiar name coral pink. So the pink color which is seen in the coral reefs. The size is 0.2 mm, marginally Jinjeva and sorry 0 to 2 mm marginally Jinjeva and 0 to 9 mm attached Jinjeva. Contour is scalloped and firm and resilient consistency and stipple texture. So it is developing when there is oral epithelium it joins with the reduced enamel epithelium. So once the enamel is laid down the epithelium which covers the tooth is known as reduced enamel epithelium which joins with oral epithelium and becoming junctional epithelium. So this is a junctional epithelium so this is a tooth and the oral epithelium and reduced enamel epithelium which is present here become junctional epithelium. And we have another type of epithelium which is known as sulcular epithelium which is seen in the Jinjeval crevice and also oral epithelium that is epithelium which covers the outer surface of Jinjeva. So that is oral epithelium then the sulcular epithelium and junctional epithelium. Junctional epithelium is fusion of reduced enamel epithelium which was present on the enamel surface after the tooth formation which joins with oral epithelium becoming junctional epithelium. So that is about the basic introduction part its classification marginal and attached Jinjeva, Jinjeval sulcasan endodendral Jinjeva. So now let's see the various epithelium that is oral, sulcular and junctional epithelium of Jinjeva. So moving on to the various epithelial types in Jinjeva the oral epithelium, sulcular epithelium and junctional epithelium. So this is a junctional epithelium, sulcular epithelium and the oral epithelium. So oral epithelium is keratinized, keratinized means we have four layers of epithelium in common the stratum basalis, stratum spinosum, stratum granulosum and stratum corneum. So the level of keratinization increases as it goes higher. So basal layer has cell multiplication and as it goes higher there is more of keratinization happens. So oral epithelium is basically keratinized and stratified in nature and it is also a squamous type. So there is basically three types of keratinization. One is para keratinized which has got 75% of total oral epithelium and the auto keratinized is 15% and non keratinized is 10% and there are various cells of epithelium present. The difference between para keratinized and ortho keratinized it is a level of keratinization. Basically ortho keratinized is the least common form of epithelium found in oral cavity which is associated with masticatory mucosa of heart pilot and attached to Jinjeva and the para keratinized is the most common one and para keratinized most commonly associated with the masticatory surfaces and we have various cells of epithelium. So before that we need to know the basic structure of epithelium. At basal layer we have stratum basal layer where the cell production is happening then stratum spinosum and stratum granulosum and the top layer is stratum corneum where the complete keratinization happens. So the level of keratinization is increasing as it goes higher. At the basal layer the cell multiplication and cell genesis production of cells happening at stratum basal layer. So the organelles and the multiplication mitosis feature when all are present at the deeper layers as it goes at the top layers it becomes more keratinized and nocly and other organelles will be lost and it will be completely keratinized. So we have cells of epithelium that is keratinocytes and non-keratinocytes. Non-keratinocytes is also known as clear cells. So we have keratinocytes which produces keratin and non-keratinocytes which has other functions also known as clear cell. So we have three types of known keratinocytes in oral cavity, melanocytes, langer hand cells and merkel cell. So these are very important commonly asked short notes in exam what is melanocyte, what is langer hand cell and merkel cell. Langer hand cells we have already covered previously. So we have one more cell which is lang hand cells that is different that is seen in pathology tuberculosis is a langer hand cells. So never get confused with lang hands and langer hand cells this is langer hand cells. So the first one is merkel cell. Merkel cell is nothing but which is located in the deeper layer of epithelium and they have a nerve endings and these are connected to adjacent cell by dysmosomes and they have been identified as tactile perceptors. So these are tactile perceptors which is present in the deeper cells and the next one is langer hand cells which are dendroitic cells located among keratinocytes at all supra basal layer. So near the top layer it is present, langer hand cells which are the dendroitic cells and they belong to the mononuclear phagocyte system or also known as these are the reticulo endothelial system. So it belongs to the reticulo endothelial system and which contain elongated granules and are considered macrophages as macrophages with possible antigenic properties. So it has antigenic properties which involves with immunity that is mononuclear phagocytes and the next one is melanocytes which are basically involved in melanin production. Then they are dendroitic cells located in basal and spinous layers which involve in synthesis of melanin in organelles that is pre-melanosomes or melanosomes. These organelles which contain tyrosinase that hydrolytes hydroxylates. So there will be tyrosinase enzymes in these organelles that is melanosomes or pre-melanosomes. So this enzyme which convert tyrosin to dopa that is dihydroxy phenylalanin, phenylalanin will be produced which in term is progressively converted to melanin. So the melanin will be synthesized in organelles that is pre-melanosomes or melanosomes which contain an enzyme monos, tyrosinase which hydroxylates tyrosin to dopa, dihydroxy phenylalanin which in term progressively converted to melanin. So melanin granules are phagocytosed and contained within other cells of epithelium and connective tissue. So it can be seen it as the cells of epithelium and connective tissue. They are called melanophages or melanophores. So melanophages or melanophores are melanin granules which are phagocytosed and contained within various epithelium and connective tissue. So these are the basic cells of gingiva. These are the non-keratinosides it has two types one is keratinoside and non-keratinoside or clear cell melanosides, langurhansels and merkel cell. So melanosides are involved in melanin production, langurhansels has antigenic property, merkel cell is for tactile perceptors is commonly as short nodes, gingiva, epithelium. So now we will see circular and junctional epithelium. So in circular epithelium, so circular epithelium is the this section the blue color okay so this is the orange color is the gingiva epithelium this blue is circular epithelium and this black one which is starting from the cemento enamel junction till here is the junction epithelium okay. So gingiva epithelium we already covered now we are in circular epithelium. circular epithelium which lines the gingiva sulcus so this is the gingiva sulcus so it lines the gingiva sulcus and it is a thin non-keratinoid stratified scoma epithelium without any retepics okay so it does not have any retepics in it so it is basically without any retepics and it extends from the coronal limit of junctional epithelium to the crest of gingiva margin okay. So this is the junction epithelium and its coronal end so it starts from coronal end of junction epithelium to the crest of gingiva margin so this is the gingiva margin to the crest of gingiva margin to the coronal end this is apical end this is a coronal end coronal end of junction epithelium to the crest of gingiva margin okay. It is a semi permeable membrane and it shows many cells with hydropic degeneration and unlike the junction epithelium the circular epithelium is not heavily infiltrated with PMN that is cells which is involved in inflammatory process so it is not very common in circular epithelium so these polymorphonucleus cells which are not very much infiltrated in circular epithelium whereas in junction epithelium is highly infiltrated and it appears to be less permeable in nature whereas a junction epithelium it is consist of a color like band of stratified squamous non-characterized epithelium it is okay the length of junction epithelium from 0.25 to 1.35 millimeter and it is 3 to 4 layer at the beginning and as age goes as a person ages it reaches up to 10 to 20 layers so we have seen it is formed by oral epithelium and reduced enamel epithelium okay so the part of oral epithelium and after tooth formation there is something called reduced enamel epithelium here so it is joined by formed by the combination of reduced enamel epithelium and oral epithelium so it is formed by confluence of these two epithelium and junction epithelium is attached to tooth surface by something known as epithelium attachment and internal basal lamina so this is called internal basal lamina so this is attached to the tooth surface here attached to the tooth surface by internal basal lamina which is a epithelial attachment and it is attached to the ginger well connected tissue by a external basal lamina okay so to the tooth surface it is attached by internal basal lamina and it is attached to the ginger well connected tissue by an external basal lamina so internal basal lamina and also there is something known as external basal lamina. So external basal lamina, so external basal lamina the junction lepithelium is attached to the jeep javel connected tissue whereas internal basal lamina is junction lepithelium attachment to the tooth surface okay and the attachment of junction lepithelium to the tooth is reinforced by the junction lepithelium fibers so there will be junction lepithelium reinforcement. So junction lepithelium reinforcement will be there so this is external basal lamina here internal basal lamina here and junction lepithelium fibers reinforces it which raise the marginal gingiva against the tooth surface okay for this reason the junctional epithelium and gingival fibers collectively known as dendo gingival unit it is a functional unit okay so gingival fibers and the junctional epithelium collectively known as dendo gingival unit which is a functional unit now let's see the functions of junctional epithelium junctional epithelium firmly attached to the tooth surface we know by internal basal lamina which forms an epithelial barrier against the plaque bacteria okay so it acts as a protective barrier against the plaque bacteria and also it allows access of gingival fluid inflammatory cells and components of the immunologic host events to the gingival margin so from the gingiva inflammatory cells will be exudated to the it is a as we discussed it is highly infiltrated with polymorpho nuclears so there will be access of gingival fluid inflammatory cells and components of immunological defense mechanism through the to the gingival margin and junctional epithelial cells exhibit rapid turnover rate which contributes to the host parasite equilibrium and rapid repair of damaged tissues so it has basically three functions one is rapid turnover rate which helps for repairing damaged tissues and immune defense there will be infiltrate coming from the fluid to the gingival margin and it acts as a barrier against plaque bacteria so gingival fibers are basically collagen fibers collagen bundles of fibers seen in the connective tissue of gingiva so which are known as gingival fibers so it is basically a type one collection so these connected tissue of marginal gingiva which is densely collagenous which contains a prominent system of collagen fiber bundles which are known as gingival fibers consists of type one collagen so functions are to raise the marginal gingiva firmly against the tooth and to provide the rigidity necessary to withstand the master category force without being deflected away from the tooth surface so bearing the master category force to unite the free marginal gingiva with the cement of the root and adjacent gingiva so uniting the free marginal gingiva with cement of root and adjacent gingiva so these are the functions of gingival fibers now let's see what are the fibers so hope you can see this picture so let me tell you this is a enamel so this part is enamel and this is enamel this part and this is alveolar bone enamel alveolar bone and this is our gingiva okay so we have types of fibers circular dendro gingival dendro periosteal and transceptor so circular fibers are fiber bundles which run their course in the free gingiva and circle the tooth in a cuff or ring like fashion so circular gingiva will not be shown here this is a cross section so you can see the circular gingiva here which circles from the top view this is the top view of gingiva this is a side view so circular fibers you can see this circle orange color circle which is circular gingiva which are the fiber bundles which run their course and the free gingiva it encircles the tooth so it encircles the tooth it is not easy to show here so it encircles the tooth so that is circular gingiva now we have dendro gingiva that is dendro gingival fibers which are embedded in cement of the supra alveolar portion of the root and it projects from cement in a fan like configuration out to the free gingival tissue of facial inkle and inter proximal surface so you can easily understand this this is dendro so it starts from cement and it is fanning out to the free gingival tissue of facial inkle and inter proximal surface so it starts from here it goes like this that is dendro gingival fibers now next one is dendro periosteal okay so this is a dendro periosteal it starts from cementum it ends in bone so this is a periosteum this is a bone so dendro periosteal fibers so it starts from cementum and it ends in periosteum so these are the embedded in the same portion of the cementum as dendro gingival fibers but they run their course apically over the vestibular and lingual bone crest and terminate the tissue of the attached gingiva okay so this is going apical direction dendro gingival going coronal direction so this blue color this violet color is dendro gingival and the pink color is dendro periosteal okay this is the bone so gingiva so from cementum so this is cementum okay so cementum it is going so this is enamel this is cementum cementum so from cementum dendro gingival and dendro periosteal now we have the transeptile fibers so transeptile fibers you can see here okay this one just connecting between two tooth they extend between the supra alveolar cementum of adjacent teeth so this is between the teeth this is cannot be seen from a side view this should be from top view so this is a transeptile fibers it is it is running between the teeth that is a it is runs straight across the inter dendro septum and are embedded in the cementum of adjacent teeth okay so it was between the teeth okay so it is run straight across the inter dendro septum so inter dendro septum is here it is going like this this blue line hope you can see this blue line between the teeth it's known as transeptile fibers and we have additional fibers which is given by pH and co-workers they are semicircular transeptile inter gingival inter papillary inter circular and periosteogen gavel okay so periosteogen gavel is here so it starts from periosteum it goes to the gingiva and this is circular we have already seen this is inter gingival it is between the gingiva this pink one and transeptile gavel it is going between the tissues gingival tissues transeptile gavel and so the remaining fibers are indigen gavel this pink one transeptile gavel this black dot the inter circular and inter papillary so inter papillary is this horizontal lines horizontal violet lines inter papillary and inter circular and periosteogen gavel I have already shown so when question asked about internal fibers we need to draw both the pictures so this is the principal fibers and this is the additional fibers circular dendro gingival dendro periosteogen transseptile additional fibers are semicircular trans gingival inter gingival inter papillary inter circular and periosteogen gavel okay so till now we were focusing on the epithelium epithelium and its various elements various cells and gingival fibers and parts of gingiva now let's move on to the connective tissue so connective tissue part which is composed of collagen basically around 60 percentage then we have fibroblast around 5 percentage and the remaining 35 percentage includes matrix which has vessels and nerves so it is known as lamina propria the connective tissue of gingiva is known as lamina propria which has got two parts papillary layer and reticular layer this papillary layer which is adjacent to the epithelium which consists of papillary projection between the epithelial retipix and reticular layer which is in continuous with periosteum of alveolar bone okay so this is includes connection with the alveolar bone contiguous with alveolar bone and papillary layer is here so this is the connective tissue papillary layer which is with projections between the epithelial retipix you can see the projections okay so this is the papillary layer and this part is reticular layer and connective tissue has cellular and extracellular compartments composed of fibers and ground substance so ground substance is basically composed of proteoglycans, hyaluronic acid, contritin sulfate, glycoproteins, mainly fibronectin and fibronectin which binds fibroblast to the fibers and many other components of intercellular matrix helping mediate cell adhesion and migration that is fibronectin fibronectin which fibronectin and we have one more protein which is known as laminin so fibronectin which binds fibroblast to the fibers and many other components of intercellular matrix whereas the laminin is another glycoprotein which is found in the basal lamina serves to attach it to the epithelial cell so it is attaching to the epithelial cell okay epithelial cell and we have three types of connective tissue fibers collagen reticular and elastic fibers the collagen type 1 forms the bulk of lamina propria and provides a tensile strength to the gene travel tissue so we have collagen reticular and elastic types and type 4 collagen which branches between the collagen type 1 bundle and is continuous with fibers of the basement membrane so we have type 1 and type 4 type 1 forms the bulk of lamina propria whereas a type 4 which branches between the type 1 so type 4 and type 1 is it type 4 is going between type 1 and it is and is continuous with fibers of basement membrane and other blood vessel so the elastic fiber system is composed of oxytaline elunine and elastin so the cellular elements so cellular elements include fibroblast which is a major element which are mesenchymal origin and plays a major role in the development maintenance and repair of gene travel connective tissue which synthesize collagen and elastic fibers as well as the glycoproteins and glycosaminoglycans it regulates collagen degradation through phagocytosis and also we have mast cell which are numerous in connective tissue and also we have fixed macrophages and histiocytes and also adipose cells and esophilus neutrophils plasma cells and lymphocytes so the blood supply of ginger is basically from three sources one is supraperiosteal arterioles supraperiosteal arterioles along the facial and lingual surface so facial and lingual surface of the alveolar bond from which capillary is extend along the circular and ginger, circular genjival epithelium and between the retapix of external genjival surface so that is supraperiosteal arterioles next to we have vessels of periodontal ligament which extends into the genjival and anastomers with capillaries in the sulcus area okay and third one is arterioles which emerge from the crest of their interdental septum so that is a blood supply lymphatic drainage from antibular incisor region it goes to submental lymph node from maxillary palatal genjival it goes to deep cervical nodes, buccal genjival of maxilla and buccal and lingual genjival in mantibular primolar molar area which goes to submantibular lymph nodes and nerve supply is basically trigeminal nerve so that was just some finishing points about genjival, about the blood supply lymph drainage on nerve supply and the cellular elements connected tissue part so genjival is a very vast topic the parts of genjival and the genjival fibers about the epithelial cells are very important for your exam so I'll come up with periodontal ligament in my next session thank you


Alright, next up please give a warm welcome to Scott Arsazowski, he's going to be giving a talk called Mill Way Jose, Designing Cryptography Features for Mirror Mortals. Welcome Scott. Hey, thanks for having me here. As she said, my name is Scott Arsazowski, you might know of me from some of my open source projects online through Paragon Initiative Enterprises. You can blame me for getting lip sodium into PHP 7.2 and for rewriting it in PHP. My Twitter handles Cypher Coder with PHP in it and sometimes I live up to that name. Which kind of goes into the whole point why we're here today. Everybody in security knows that you should not roll your own crypto, right? That's common knowledge. It's actually repeated a lot on the internet and everyone knows it. It's common wisdom and there's good reasons for it. If you follow the work of Bruce Schneier, you know that amateurs produce amateurs cryptography. It's very difficult to get right. You might think it's secure and then find out you have a timing side channel. Even people who have been experts in the field for years make mistakes. And the problem is that the buck usually stops there. Developers are told don't build your own. But that's it. They're just told not to. So when people say, okay, instead of rolling my own, what should I do? They're often told something like this. And I copied that from my friends at Latakora. So most developers work, they do line of business software development of some form. Crowd apps, moving data from point A to point B. Sometimes they do really cool stuff with machine learning. But usually if they need encryption it's to protect data they're storing. So they have business goals. So they just need to solve problems. And they need easy to use tools that will just solve the problem and get out of their way. Without exposing them to, you have to select this particular configuration for it to be secure and you have all these options to research and learn about. And let's take a look at one really egregious example of this. It's called Jose, the JavaScript object signing an encryption standard. Some of you might be familiar with it. It's a family of standards with several RFCs. Most of them relate to authenticated tokens either signed using public key cryptography or secret key cryptography or they're encrypted. People use them for all sorts of things. They're supposed to be used for short lived claims. Like if you have a third party download server and you want to say, yes, they can download this file once. That's the envisioned use case. People abuse them for like stateless sessions and all that. And it was never really designed for that use case in mind. So if you look at the RFC, you can see a lot of text that explains pretty much what I just said. The important thing is that a JWT pronounced jot uses either encryption or a signature algorithm. So consequently, if there's a JWS or JWE vulnerability, it probably applies to your JWT library. And there's implementations of JSON web tokens in pretty much every language. Most developers use them whether they realize them or not. And here's what they look like. Now you have a header, you have the message, and then you have your signature. Now let's take a look at the JSON web signatures real quick. You have this thing called an ALG header, which was the red in the slides up here. That tells you what algorithm you're using and what type it is. There's different options. You have HS256, you know, HMAC SHA256. You have RS256, RSA with PKCS1V1.5 and SHA256. And you, of course, have none. This is the textbook bad API design mistake. It's mixing symmetric and asymmetric cryptography in the same context. And unfortunately attackers are the ones who provide the tokens, which contains all this metadata. So they can choose the header. And so, you know, this sounds dangerous. And it actually gets worse than that. Because in the RFC that defined JSON web tokens, it says the header parameter must be present and must be understood and processed by implementations. And if you've ever worked with software developers, you'll know that that means obeyed, right? They don't parse standards the same way that people that write them do. They say, oh, it must be processed and understood. That means we have to adhere to whatever a token says. And this has led to vulnerabilities that we've probably all heard of before in JSON web token libraries. JSON web encryption is now much better. Look at these key encryption options, right? This is for encrypting a key to the later on encrypted token body. Now, if you noticed, we have three asymmetrical ones and one symmetric key option. This was clearly not the result of careful designing of use cases. This was a design by committee of trying to solve the 99% problem rather than the 50% problem at day one. Furthermore, the ECD-HES, which is looked at Curve Diffie-Helman encryption, something like that. The way they specified it in the Jose standards opened the door to invalid curve attacks, which allow an attacker to keep feeding you tokens and then steal your private key. The reason why this is the case is that they say it must specify the X and Y coordinate of your public key point. What it should have done is either only specified one of the coordinates and a signing bit or make point validation a explicit part of the standard. And they did neither of these. So that's some of the problems built into the Jose standards. There's a more general problem. So they say, okay, let's give developers options. My friend Taylor Hornby wrote a blog post about this where he called that reasoning by Lego. And you see a lot of this in the internet, especially early 90s and early 2000s crypto designs, like people who do Mac and encrypt, not Mac then encrypt or encrypt then Mac, people say, well, we have a secure Mac function and we have a secure encryption function. This should be secure. But it's not the two pieces that make the protocol secure. It's also how it's joined together. So to put this in layman's terms that a developer would understand. You're building a brick wall, right? But instead of putting bricks in lane mortar and then putting more bricks and more mortar, instead you have this mesh with empty space of just mortar in place. And you're supposed to slide the bricks you prefer into place.  Would you trust that wall to hold up the roof? That's how cryptography libraries and standards have been built historically. TLS is no exception, although 1.3 is a hack of an improvement. So to pwn or jot to pwn, there are a lot of ways for the standards to go wrong. We've seen some of them in CVEs over the past three years. We'll probably see even more. There's a lot of RFCs that I haven't even had time to delve into the specify weird cipher modes. And then there's implementation security risks and user error. Somebody could just say, okay, I'm gonna make the, you know, JSON web token key their username. And then I'll use that for HMAC validation. That would be a user error. And then implementation specific would be a library that like has a timing attack vulnerability in the, you know, Mac validator. Whenever I would raise these criticisms of the standard to the people who design and advocate for Jose libraries, or Jose, the response was always, well, you should use one of these libraries. You should use this one. We've vetted this one. Don't use the other one. That doesn't really solve the problem. It shifts the blame from the badly designed standard onto the libraries developers and their users, the people who are trying to choose a library. And if we want to build secure systems, this is an anti-pattern. That bears emphasizing. And there's an entire series of anti-patterns at play here. So the people who design standards say, let's give users lots of choices. In case one of them turns out not to be a good one, then we can just deprecate that down the line, which never happens. You still see systems using RC4 today. Their advocates will blame the implementation rather than the standard. Security experts will say, we'll look at this and say, okay, well, don't use the standard. Don't use JWT. And then developers roll their own crypto because they're not given an alternative. And this is what happened with JSON web tokens and the other half of my talk that I wanted to go into. So can you really blame developers for rolling their own crypto when they're not given a viable alternative to bad designs? I say no. If our goal is to stop badly written cryptography from being put out in the world, which means having non-experts design it, we need to design a better standard that's easy to use securely and hard to use insecurely. With that in mind, I designed POSETTO, platform agnostic security tokens. You can see how it's pronounced there. When I set out on this, I had a few design goals in mind. I wanted to minimize runtime negotiation. That's where you would say, okay, well, you have these ciphers you can choose from. Now pick from this list. I wanted that to be completely trimmed down as much as possible. I wanted versioned tokens built in versioning. So that way, if you have version one and version two of the standard, and then version one becomes critically insecure where you don't want to run anymore, and version two is implicated because of some new attack, you can design version three and then migrate everyone onto that. Like let's say a practical quantum computer comes out and that breaks all of elliptic curve cryptography. So each version has its own one true cypress suite. You don't have a lot of options. It's either, I'll go into what the options are. You're using version one or version two or version three. Less knobs and levers to people to play with and get wrong. And that's pretty much it. That's the main design philosophy I took that was different from the pose standards. So since I showed you a JSON web token, this is what the structure of a possedo looks like. You have a version, pretty obvious from everything I've said. You have a purpose. They're called local and public. And the difference is not subtle. Local is symmetric key authenticated encryption. Public is just a digital signature using RSA for version one or ed25519 for version two. And you have an optional footer. The reason for an optional footer is because some people want to do a key rotation. So they would want a unencrypted part of a local token. They could store like a key identifier that references a specific public key or a specific secret key. Everything is base 64 URL encoded as in defined in the RFC and joined by period characters just like JSON web tokens are. So the version defines the Cypher suite. The purpose tells you what it's doing. And the footer is optional for key rotation schemes. Envision use cases is pretty much the same use case that JSON web tokens is supposed to be solving. Short live, one time, third party access tokens. That was all it was designed for. They throw all this complexity and machinery on top of it for solving every use case with one tool. And more specifically, I want to eventually integrate this into something like OpenID Connect so people can use this instead of JSON web tokens for OAuth. So as I said, there's two versions defined in the initial run. There might be future ones when quantum computers become a more imminent threat. Compatibility mode uses open SSL. Like the ciphers that almost everybody's familiar with. RSA, AES uses SHA-2. Specifically, it uses AES-256 in counter mode. HMAC, SHA-384, and Encrypton Mac. And then it uses HKDF to split the keys. I use SHA-384 just as a standard hash function. There's no reason 256 wouldn't have worked or 512 wouldn't have worked. But there are a lot of people who will look at it. One subtle decision made somewhere in one standard and reapply it everywhere. So if I went with SHA-256, developers would assume that SHA-256 was secure. Never mind that there's length extension attacks and whatnot if they decide to build their own MAC protocol with that. And then public key signatures. If you've worked with RSA, you'll probably be relieved that PKCS 1V1.5 is not here. Instead, you get the probabilistic signature scheme, the secure RSA signature scheme with a hard-coded set of parameters. And then you have the recommended version. This is the one I actually want people to use, but they might not have Libsodium, which is what I'm using as a basis for this. Specifically, it uses the extended nonce SHA-20 Poly 1305 AEAD mode. And then it uses ed25519 for signatures. So let's look at one. So in this example, the payload is foo and the footer is bar. This is a local token. It's color-coded. Okay, it seems to show up pretty well on the slide. You can see that you have the version, the purpose, a payload, and then a footer at the end. And here's the key that actually generated this if anybody wanted to download one of the many libraries that implement POSEDO and play with it at home. And here's a public payload. You can see that the string changed from local to public and it's a little bit longer because it's a digital signature. But you see the first four letters of the yellow, that will not change because that's actually plain text. And then if you look at it, oh yeah, here's the keys. Without a footer, it just looks like this. And if you go back and forth quickly, you'll see that the first four letters of yellow did not change because that's bar in base 64 URL. That's what they look like. That's what developers will see. They don't really need to know all of the internals, but considering this is a crypto village talk, I'm gonna go into them a little bit. So for all versions, there's a couple of rules that I wrote into this proposed standard that will eventually hopefully be taken seriously by the IETF and accepted as an RFC. I have a first draft submitted to them, got some feedback, I'm working on the second one right now. The first rule is to, for randomness, is to use u-random. Specifically, or more broadly, the operating systems cryptographically secure random number generator. You're not allowed to use a linear congruent generator or a marxine twister or any other insecure user space design. That's a standard rule. If you're doing that, you're deviating from the standard and you shouldn't do that. You know, no in-CCA2 insecure public key cryptography. Specifically, I would call out this padding mode for RSA. It will never be allowed. If anybody suggests that the answer's gonna be no, closed, won't fix, works as intended. And the reason is because I hope I'm pronouncing his name right, Blikenbocker, had that 1998 padding oracle attack that's still relevant 20 years later. It's old enough to drink. I think it's high time we stopped building that padding mode into new protocols and designs. And Robot just won a Pony Award at Black Hat, so congratulations to Hanobock and his team. And finally, when possible, do everything in constant time. This includes Bay 64 URL encoding. I will post these slides online afterwards. That actually links to a PHP library that implements Bay 64 encoding without any cache timing side channels. So another thing that's built into the standard is what's called pre-authentication encoding. This isn't really an immediate security concern, but there's a class of attacks based on how you feed data into your message authentication code called mechanicalization attacks. So basically, this is just a proactive measure to ensure that every message doesn't create collisions from having multi-part messages. So you can't just append a bunch of data and have it match a signature that has a footer that originally didn't have a footer so you can forge it or anything weird like that. So what we do here is we prefix it, we take the number of pieces and we turn it into a string, a binary packed string representation of that number and little indian as 64 bit. And then for each piece, we do the same exact thing, we prefix it with the length in the same encoding format and then we put the string. This might sound a little weird, I'll get to what it does in just a second. So when a passato is being encrypted, instead of just feeding the cipher text into the message authentication code, you know, HMAC, it actually does the pre-authentication encoding and takes that output of all those pieces and then uses the HMAC of that. So this will authenticate not only the header v1.local, it'll also authenticate the nonce which is generated randomly, the cipher text and the optional footer. The same thing happens with the RSA signature, it covers the header, message and optional footer, which will be just an empty string followed by null bytes if you didn't specify one. For version two, subtle difference between how the crypto-AEAD interface works, it already authenticates the cipher text, you can specify your additional data, so it just packs together the header, the nonce and the footer for version two. And that's because Libsodium and other implementations of the same protocol already authenticate the cipher text, this is just the additional data. And then add25519 is exactly what we'd expect if you looked at the RSA slide previously. So let's compare that to you real quick. JSON Web Tokens has a lot of options, including unauthenticated options. It promotes reasoning by Lego, which you have two pieces that doesn't necessarily mean they're secure if they're not glued together properly or in the right order. And it's often abused for stateless tokens. That's something that most people will criticize JSON Web Tokens for and they don't really look further because that's what most developers are doing. Pasoedo, you have two options, you have version and purpose. Everything's authenticated and your local tokens are always encrypted so you don't accidentally leak sensitive information for a local system. It does its job and it gets out of the way. People can still abuse this for stateless tokens, but it doesn't have the built-in habit in the community yet. And I've been actively discouraging it when people ask if they can use it this way. So hopefully that won't be a re-emergent issue. If it is, of course, that's what the security industry's here for is to tell them not to do that. If you'd like to learn more about the standard I'm trying to build, you can go to pasedo.io or github.com slash paragonie slash pasedo. And you can look and see the RFC draft as it's being written and marked down. You can look at the reference implementation and PHP. If you look at the first URL, there's like implementations in about 11 other languages. That number is gonna go up when I get home because I have a couple to review when I get back. So that's just an example. A very important one in my opinion, but there's a more general topic here. It's about designing cryptography for humans. Using the examples that I just gave you, if we want developers to build secure software and we give them crypto building blocks that are actually secure, that won't fail them. But in order to do that, we have to know how to design cryptography for humans to use safely, you know, mere mortals, humans, developers, whatever noun you wanna use there. So you should have an opinionated interface. This should be your API for any encryption library. You have your message, your key, and an optional data to include in the authentication tag. Your decryption should be exactly the same. You shouldn't have to specify a mode. You shouldn't have to even know what a nonce is, let alone the subtle difference between a nonce and an initialization vector, which does anybody here not know the difference between a nonce and initialization vector, aka IV? Okay. So you should have hard-coded version protocols, which means that, like Paceto, you have version one and version two. You don't have version one in ECB mode and version one in CBC mode and version one in counter mode. You just have version one. And they should be vetted by cryptographers. If you're not a cryptographer and you want to design one, you should hire one to audit your design, like give you a protocol review, give you recommendations, et cetera. And if a vulnerability is ever found in the current version, a new one should be published with a better hard-coded cypher suite instead of giving people options. Because if you give developers options, a lot of them are gonna choose partly, and that's how we end up in the situation we're in today. This is different from what a lot of other people will believe in. When you're designing cryptography libraries and you're working with keys, don't just accept binary strings or byte arrays. Encapsulate them in an object, specifically a typed object. If you have a signing secret key for asymmetric cryptography, that should be distinct from your symmetric secret key. Even if they're the same bit length, even if you generate them from the same randomness device, you wanna keep a little bit of type safety there. That also discourages them from using their passwords as their key, which if you've worked with PHP developers, that problem is more commonplace than we even wanna get into. And there's an additional benefit here. I'm not really at liberty to go into how often this one turns up in my work, but it's a lot. Stack traces and uncaught exceptions and error codes ending up in automated bug reports, sent in emails or published to Jira or track, left in the bug tracker for years and years and years. So when you go in and you look at their bug tracker, you can just grab for password and you can find a lot of their users real passwords because they're being passed around the strings and the programming languages that people work with don't assume it's sensitive. It just goes, oh, it's a string. I'm gonna include it in the stack trace to be helpful. So if you encapsulate it in an object, you can actually hide it from stack traces easily. My friend Taylor, who coined the phrase reasoning by Lego, actually wrote a PHP library. You've probably heard of it as defuse slash PHP encryption. And that was one of the main departures from the norm that went to that design. Always logically separate symmetric from asymmetric cryptography. So that way people don't try to use RSA to encrypt something that doesn't need the overhead or complexity of asymmetric cryptography. If you're storing it in a database and your application that's writing it needs to be able to read it, you don't need RSA. Just use AES. Java and their built-in cipher is the probably most egregious example of violating this rule. Failure remotes. So when PHP 7 was being discussed and they were adding a new cryptographically secure random number generator API to be consistent regardless of OS and all that, the original run would return false if it couldn't generate random number securely, which PHP is a weekly typed language. A lot of people would say, you know, set this letter of a password to an index of an array based on the random int that was just generated. So if you have a random integer and it's set to false, it's gonna return a zero, you're silently gonna end up with passwords that will look like the letter A repeating 10 times. So the best thing to do for designing a library for developers to use is to throw exceptions or whatever equivalent error handling mechanism the programming language allows. This way, if they catch the exception, they can fail gracefully. They can have their pretty error page. They can silently encrypt and email a report to the developer saying, hey, this broke and it shouldn't have, you know, this is a high alert, fix it now. Or they can just log into a bug tracker, whatever they wanna do. If you fail closed in a way that doesn't allow them to catch the exception, like if you just have a fatal error, developers won't use the new API.  It's like, okay, well, this is gonna crash. It's gonna make my system unstable. I'm gonna get the call at two in the morning to fix something that, you know, is a random error. And that just makes them nervous. They won't wanna use it. And they'll go back to using RAND and MT-RAND forever. And then, you know, the exception being the mid-ground between the two. And you don't wanna fail open, like the first example bit. Eventually, that was ironed out and when 7.0 launched, PHP does the right thing. Okay, so just a quick recap. Oh, actually, this is the recap. The blame game doesn't solve insecurity. Telling developers don't use JDUT, like many security experts did last year and not giving them something viable to use as an alternative. They're just gonna either keep using it out of spite and they're gonna stop listening to you or they're gonna invent their own or they're just gonna say, screw it, let's not even sign anything, let's just store a token that's completely plain text. If you don't give them an option that's better, they're gonna probably choose a poorer one because that's all the options they have. The only way to really prevent people from designing their own cryptography and implementing it and publishing it in a way that, the one time I amateur designs here is to give them something that already solves a problem for them that's easy enough to use to where they won't have the incentive to get creative.  Your API should always be simple to understand. Whenever I talk about crypto documentation, I say every asterisk is a disaster risk. I strongly believe in preferring version protocols over cipher agility and error prone standards should be deprecated in favor of safer ones for developers to use. At that point, do I have any questions? All right, let's give it up for Scott. Thank you.


Welcome back to my channel. If you're new here, hi, hello, I'm Lydia Why's my window open? Open my window and why? So today is a requested video from here So I thought we would be that video today Now if you've followed my channel for a long time, you will know that I've had some involvement with the police and my mental health There's one incident I'm not gonna talk about today and that is when I got arrested because yes It's meant to help later and it was traumatizing. I still haven't gone over it. I don't want to train on myself So aside from that, I'm gonna be talking about my good and bad experiences mental health and the police before I jump into this video I'm gonna put a trigger warning for suicide attempts because it's kind of how they became involved I don't want this to be something that's used as a tool to give people ideas I'm a sharing these details because it's an experience with police So if you think you'll be triggered by anything I have to say regarding attempts on my life, please click off this video now So let's start with the most traumatizing one to me anyway that I've been through now I was living in Sturburton. So it's about three years ago now and I and I Went and client over the other side of the bridge because I really was done and Two police officers came running behind me and pulled me over Backwards and put me on the floor with my hands behind my back And so Lydia, you're the thing you under the section 136 the mental fat and when we got on the ambulance They put leg restraints on me because I kept trying to get up and leave but I didn't want I didn't want help I wanted help I would have seeked it. I wanted to die but the only leg restraints one was so restrictive and it reminds me so much of When I got arrested because this is something that was used on me then So it is easily the most traumatizing attempt When we're in hospital, they wouldn't take leg restraints off Until I had to go to the bathroom. They didn't want to carry me yet. Having to piss in front of a police officer Is something you will never get used to it Another one would be where I live in Lancashire and in Lancashire, most of you know this I used to go out drinking pretty much on another dayling and I drank a lot My alcohol tolerance was pretty good and never threw up because of alcohol. I've never thrown up because of alcohol I just I passed out a lot, but anyway, I collapsed outside a police station Can't make this shit up Passed out outside a police station and from what I've been told by police officers Is they found me unconscious No one with me. Thanks friends. This is why I don't have friends. Yeah, the police sectioned me For being in intoxicated on my medication, which shouldn't have been drinking on. I Can't drink now. I really want a vodka coke or an arches and lemonade. That would be nice But yeah, I didn't mean to any that she cuffed me to the bed both sides another time We have is when I was took straight to a 1 3 6 week Which I'll try and find a picture of to put here a 1 3 6 week is a place of safety The only people on section 1 3 6 can be taken they end up sedating me once I arrived because I was psychotic and manic and About ready to punch a window thinking I was invincible. I didn't get to punch the window I have a lot of experience when it comes to police and mental health So if you want me to make The part of this let me know in the comments down below If you have any questions about Lancashire police, let me know if you need questions about Met police Let me know two different police forces So Got you here. I remember one time I was living in Wembley five years ago five years ago And I left the flat because they said I wanted pressure And the police said they wasn't gonna section me And I got outside the building I thought what happens? Lydia was detaining you into section one three six the mental health act But yeah, that's all I thought for this video if you are new make sure you hit the subscribe button and I will see you in my next one Peace