 Everybody I'd like to introduce you to Taylor Kempel Taylor was one of the few people who sent multiple Pretty good talk suggestions to the program committee and we randomly selected this one But how did you randomly select it? So welcome to the entropic principle about dev random and dev you random I Don't actually know of a concept called the entropic principle I just thought it sounded funny when I was thinking of a title So I'd like to start by saying if you don't take anything else away from this talk Just know that When you're writing an application and you need to make a random choice use dev you random it's a safe thing to do it'll work anywhere and Even though you might have this notion that it is it is only a a false idol of randomness Or it's only pseudo-random not really random. That's actually not really right. It's it's it it'll work So dev random and dev you random our device nodes on pretty much any modern unique system They have the property that when you read anything from them when you read a bite from them Nobody can predict other than the kernel what that bite you will read is They also have the property that you can Influence what future reads will Yield by writing to them, but I'll I'll get that later about entropy sources Now they're different in that When you read from dev random rather than dev you random They're random will sometimes block now The usual explanation of what's going on there is that there's something about information theory and real randomness versus pseudo randomness and But really the real difference is that dev random sometimes blocks and dev you random never blocks And there is no shortage of Very confused verbiage on the internet about what the nature of the difference is but that's the real difference is dev random blocks dev you random doesn't so Why does it matter that it be unpredictable? Well, there are bad guys on the internet when you're writing any sort of Engineering system that talks to the internet. It is your responsibility to make sure that People don't eavesdrop on your conversations And they don't intercept your conversations and they will because there are there are there are people like This this character mr. James Clapper. Well, he doesn't do it personally but There's lots of nasty stuff on the internet and We need crypto in order to Avoid the nasty stuff and in order for crypto to work The parties involved in communicating over the internet need to have secrets that the bad guys cannot predict If the bad guys can can predict the secrets and the crypto doesn't work Here are some examples of where people used crypto and Failed to make sure that the secrets were actually unpredictable The There's a Taiwanese national identity database and it used a bunch of RSA keys That were generated by smart cards that are all thoroughly certified except that the well actually the certification process Didn't make sure that the random number generator actually worked. So a lot of the RSA keys had factors in common. Oops Sony used in Signature scheme for signing firmware updates Only they screwed up this the use of the signature scheme so that they accidentally revealed the signing key to the world and So anybody could sign PlayStation firmware updates Similar to the Taiwanese national identity database There was a project which you may have heard about factor ball net Just surveying machines on the internet with TLS SSL servers and found that a lot of them had Secrets that were entirely predictable and when the NSA and allegedly chose to Put a back door into a major US government crypto standard. They chose Allegedly the random regenerator. So this is obviously a very important part of ease dropping and interception Now whenever we're talking about a Security system In order to avoid The sort of voodoo that you encounter in discussions of lots of discussions of dev random and dev your random you have to have a An application in mind. What are you trying to accomplish with this system? You have to have a threat model who is trying to screw you up And you have to have a set of intended security properties. What are you trying to make sure the bad guys can't do? So in this case we are trying to Just generate bits with uniform random distribution There are several possible threat models who I consider Very easy one is that the attacker might be reading from dev random or dev you random on the same machine Now maybe not by running a process on that machine, but maybe by looking at the TLS Packets on some other conversation which reveals some output. That's usually directly from the application general regenerator Another threat model is that the attack you may try to influence dev you random by feeding in By feeding an entropy from either by like bang on your own keyboard or by sending network packet timings Which are where is to places where the operating system? Tries to Derive some of its random decisions another possible threat model is the attacker can totally compromise your machine and Get at the totally complete internal state of kernel memory now This is not a threat model that you can do all that much about but there is one thing that That that we that we can defend against with that which is about Making sure that if you have generated a key from dev random or dev you random in the past and somebody later Compromises your machine. You want to make sure that they still can't predict what your key was So these are three different threat models that are relevant in In discussion discussion of dev random and of you random and any time that you're worried about the security properties You need to consider the threat models that they the properties are relative to so we want to make sure that Whatever the attacker is They shouldn't be able to predict any output from dev random or dev you random that they haven't seen before Now if they get the total internal state they can predict future outputs because if your machine is rooted then you're hosed in the future but They shouldn't be able to predict any past ones. They shouldn't be able to figure out what PGP key you generated last week so in order to I Discuss what? Unpredictable to an attacker means we have to have some formalization of unpredictability And we're going to use the language of probability theory Very briefly in just a couple of slides to talk about that So a random variable is just a model for a physical system that you can imagine observing and you can imagine it taking on some particular value say little x 0 little x 1 whatever now and We have a probability theory notation for writing what the probability of observing one particular value of this Random variable of this physical system is Now given a random variable We need some way to measure how unpredictable it is because random variable here just means that there is some level of uncertainty In what you might observe But doesn't mean anything beyond that doesn't mean uniform random for example So the usual popular approach of measuring how unpredictable a Physical observation a physical system a random variable is is Shannon entropy and you've probably heard of information theory and Entropy in the past and this is the formal definition of it Roughly it gives the if you have in a physical system that has some number of bits of information Literally like it you have you consider you know a pair of coin flips that has two bits of information well two bits of output literally But if the probability of if for some reason you're gonna flip always heads For both of them or always tails for both of them and you're never gonna flip heads for one and tails for the other or tails for one heads for the other then the entropy in this physical process of flipping two coins is only one bit of actual entropy per bits of the random variable so the The rate of information is is one half bit of entropy per bit of output So that's the popular thing that you will encounter in in the information theory and especially in coding theory and Discussing you know care-correcting codes and communication channels and whatnot But it's actually not terribly useful for crypto because if we have some random variable big X say and there are a Lot of possibility possible observations for what X is and let's say maybe X is your choice of password And half the time you choose the password hunter to But all of the times you choose uniformly at random from the other possibilities The Shannon entropy makes it look like there's there's it looks like there's a lot of entropy in here That is it looks like there's if I wanted to if I as an attacker wanted to exhaustively Search the possibilities to looking for your password if I had some way to check the whether your whether my guess is correct Shannon entropy says that should take a long time right because if there are Well, you know if there are two to the 128 possibilities Then you have to search about half of those before you get the get the right one on average But in this case I have a pretty good guess what your password is if this is if this is the model that I have and This is how you know password crackers like John the Ripper work They have a you know the passwords are not chosen uniformly at random and John the Ripper will gas It's gonna guess password first I guess password one two three next probably and Hunter two is probably pretty high up there So instead in crypto we use a concept called min entropy which is a measure of Sort of the worst case here rather than the average case so in in the case of half the time your password is Hunter two and All the rest of the cases it's you know each each possibility has very low probability The min entropy of that is going to be one half And there's gonna be one there's only one bit of min entropy there which is Means very predictable Now if we're looking at a random variable with uniform distribution that is every possibility has the same probability For example a nice unbiased coin where the heads and tails both have one half probability Then the min entropy is just the number of Bits in of the possible outcomes if you if you have you know a one bit outcome in the min entropy of that is gonna be one If you have 128 bit string you're drawing randomly from those and with uniform distribution Then the min entropy of that is gonna be 128 and in crypto standard practice is to use if you're You know if you're making a very weak system Maybe 80 bits, but usually at least 128 or if you're a little more paranoid or worried about quantum computing then 256 bits of min entropy okay, so The colonel's job with dev random and dev u random is to make reading k bits from the device That is the physical process of reading k bits from the device that that should that should if you models a random variable have K bits of entropy So it is it is It's supposed to be very hard for an attacker to predict what the bits are and if you draw You know one bit then it's well the attacker has a small fifty-fifty chance of guessing right if you draw 128 bits The attacker has a very very very small chance of guessing right Now how does the colonel choose which bits to produce of course if the colonel is a nice single threaded Computer program that actually be determined as you know deterministic, but colonels have access to physical devices of course and they make various non-deterministic non-deterministic observations of the Physical devices that are attached to them for example the computers really have more than one clock in them and two clocks are never quite synchronized right So if you look at the skew between the two clocks That may be a little bit harder, you know a little hard to predict if you're not actually Observing the fox herself so if if you are an attacker on the other end of the ethernet cable It may be hard for you to observe the two oscillators inside The computer you're trying to attack other possibilities are the timings of network packets or Keyboard input, you know what how far apart my keystrokes are and which keys I'm hitting So if you run GPG dash dash gen key to produce a new key, it'll print out a message kind of like this Well, not literally this but Asking you to bang on the keyboard like a monkey until it has an f-entropy to generate the key So all of these Devices that the colonel observes are themselves random variables, but they don't have nice uniform distribution the Spacing between my keystrokes is very much non-uniform right now. I am not typing any keys at all So there's a very long gap, but if I were to go and type the URL to this presentation Then there would be a whole bunch of very short gaps. So it's not it's not uniform at all and sometimes these Sources of entropy are Under the influence of attackers so if you have a network attacker and you are using the time between network packets as a source of entropy As a source of unpredictability for dev random on your system then well Maybe the attacker can send packets on very regular intervals, you know Maybe every millisecond or something or every 10 milliseconds Or if the attacker is trying to log into yours Unlock your screen lock. Maybe your attacker can bang on the keyboard very Robotically rather than like a monkey and so that Yes, well or the the or the attacker can hold on to the space key until the screen locker crashes, but that's a separate issue so In order to do this the colonel uses some crypto magic called an entropy extractor and I'm not going to go into the details of all the all the crypto here And so but basically it pours all the entropy sources into a funnel and mixes them around so that they look a lot more uniform rather than very non-uniform like a bang on the keyboard like a robot or You know long gaps between keystrokes and followed by very short ones and then once the kernel has mixed all this into a big funnel and Produced a little output it will use that as the seed for a pseudo random number generator That is a deterministic program that expands a short unpredictable secret into a very long sequence of unpredictable secrets Now you notice I said This is the case for dev random and dev u-random. There's no difference between them here It's not that dev random usually spits out stuff directly from the Entropy funnel the entry pool here and dev u-random makes something up and then uses a deterministic Algorithm to spit out results. They both go through the same pseudo another generator They they they both go through the same deterministic process seeded by bits from the entropy sources now What if you don't have all that much entropy what if I've just booted up the machine I just hit the power button and I haven't typed any keystrokes and it's a fresh install of my operating system and SSHD starts up and auto-generates keys Then well if I did this twice There's a good chance I would get the same results or at the very least There's a fairly small collection of results that I might get that an attacker could easily cycle through similar to the Debian open SSL debacle several years ago where the open SSL userland PRNG Was using a seed that was much too small so that there was only a very small number of possible keys that it would ever produce so This would be bad and you want to prevent Anything from trying to use entropy when there when the system is actually predictable So how do we prevent this well? The naive answer is that we wait until I have banged on the keyboard like a monkey Wait until the disk has started spinning and we've observed the heads on the disk have taken some time to move around and Or we've observed some network packets and that's enough but and then well so traditionally Dev random Will block until the system has determined that enough of these events have happened I banged on the keyboard like enough of a monkey not enough of a robot enough of a monkey Or there have become enough network packets have come in So applications can use dev random as a sort of barrier to wait for entropy to become available So you could for example you could have just an in its script In your little embedded system that reads from dev random before it launches anything that needs entropy As soon as dev random returns the kernel has determined. I think that I'm unpredictable enough Dev you random in contrast never blocks so Even if you use it early at boot before you banged on the keyboard like a monkey It will not block it will just return data that well might be actually predictable So even if there's been nothing fed into the entropy pool the kernel will use I mean It might be all zeros as a key as a seed for the PRNG The trouble is With the obligatory Dilbert reference You can't actually tell from any particular state whether that state is unpredictable If I roll it, you know D 10 six times and get Nines out as a result. That's a perfectly valid Result even if the die is totally fair and you can't tell just from looking at the output whether I actually rolled the die to Produce the result or whether I just read Dilbert What you can do in which Dilbert doesn't really? address is assess whether the process that you are using to produce the output is Unpredictable, so if I tell you I'm gonna roll D 10 six times Then well, you have the 10 to the 6 1 in 10 to the 6th chance of guessing what the right it what the outcome will be Whereas If I tell you that I got 9 9 9 9 9 9 Then well the chance of that is was one so The trouble so yes, it's it's hard to for a kernel to determine whether it is currently unpredictable It can try to make some estimates by Using a deterministic algorithm to print to try to predict itself what the next output of the entry source will be or given two outputs It will try to assess If I knew the first output would the second output be a surprise to me And so there's some ad hoc logic in most kernels that will try to guess Do these look like they're does this look like is unpredictable given the first output? And if so, maybe I got one bit eventually maybe I got two bits of entropy and it will slowly add up the bits of entropy That it has counted using this ad hoc approach until it gets to a certain threshold but this isn't really a good solution because You can you could you could certainly imagine using a You know using a sequence of keystroke timings that You got from a pseudo number generator Seated by zero so The output of that will look indistinguishable to random as somebody who doesn't know the seed was zero But if you know the seed is zero, then you can predict exactly what the resulting output will be so It's not it's There's no real good answer here You just it's just it's a matter of system engineering to decide how You know how in your whole system you can determine whether there's enough entropy There's also this other concept of running out of entropy which you'll encounter in a lot of the man pages and documentation on the web and Discussions on the web and the interwebs and and an IRC and everywhere about how Sometimes if you use a lot of data from dev random, you'll deplete the entropy pool you'll run out of entropy like running out of gas when you're driving your car or something and then all of a sudden your car slows down and it can't produce secrets anymore and and That actually that doesn't really make sense the the only way that it conceivably Makes sense in the real world. No, not in the real in the theoretical world is that if an attacker witnessed the whole internal state of your kernel and Then walked away without doing anything with it and you got some more entropy Maybe then you would want to wait a little bit after they've Read your whole internal state before trying to read more from dev random But if the attacker has already witnessed the full internal state of your kernel There's a good chance. They can do lots of other nefarious things and you probably just don't want to use that machine anymore So Why would you know that that very Peculiar theoretical use case aside, why would you want to block in dev random long after boot? Well, there actually is a reason So if you're using dev random as a sort of unpredictability barrier that is as a way to ask the system, please Wait until you know, let me know when you've got enough entropy You would like to keep that code path exercised because if you run your application on your laptop Your development laptop, you'll always have enough entropy. So it'll never block You'll never actually use the you'll never actually see the code path where the blocking happens You'll see your application just snappily goes along and read stuff from dev random and it never blocks Until you write an application that someone else at some other company uses on an embedded device And they find that it causes all of their network to hang once they did an update to add your new code And that was because you started using dev random and Now all of their devices don't have enough entropy at boot and you never tested the blocking code path And did they just never get past boot because your application never launched because it couldn't get entropy from dev random All that said that's a fairly obscure use case and most applications are Are totally happy with just using dev you random So let me reiterate if you're writing an application that needs an unpredictable secret use dev you random Now what if there are no entropy sources like on such an embedded device where at boot? It just didn't have anything There's no disc. There's no mouse. You can move around. There's no keyboard You can bang on and even if you had a keyboard the monkey wouldn't help you So in that case the system the kernel and the whole system might be totally deterministic and it can't Provide anything from dev you random usefully that is anything it spits out of dev random or dev you random an attacker can predict because they can buy The same bit of device run the same soft run and get exactly the same outputs And this is presumably what happened with the Factorable net survey that would resulting in the mining your P's and Q's paper There were presumably a lot of embedded appliances that just had no entropy and they booted up and generated the keys and on two different Appliances, it was the same keys or at least one of the same factors because there wasn't much entropy just a little tiny bit So this is a real problem in practice and Well one thing you can do is when you install Your system when you flash the flash it with a OS image Which you maybe do from your laptop or from something else your laptop probably is in an unpredictable state so you can Takes mentor be from dev random on your laptop and just store it on the embedded device in A little non-volatile storage location takes only 32 bytes to be reliable as 356 bits and that's enough for many crypto and Then You might later also want to Save it again when you reboot the embedded device and so you can restore it when you start up again So that each boot will get different outputs, so it doesn't generate the same session keys over and over again And if you do this Then you don't need in your whole system The use of dev random is an unpredictability barrier because the whole system has ensured There's your whole process of flashing the device with entropy derived from your laptop or something So the whole system has ensured that The the the the system is is always in an unpretentious always unpredictable to an attacker Now I mentioned earlier that the the kernel will Draw from various different possible sources of entropy that is various possible different physical systems and Sometimes these physical systems are under the influence of an attacker You know the attacker can easily influence network packet timings Especially if they're on a LAN on the same LAN as you for example if you're in a coffee shop and and the attacker is on the same Wi-Fi network Sometimes you tackle good influence keystroke timings. I mean if you leave your laptop unattended and the attacker can just walk up and type at it Sometimes you might be worried about the attacker Compromising your CPU and this sounds really far-fetched But it is I see some people shaking their heads here because to them it is not far-fetched, but You might argue that if an attacker can compromise your CPU then what's the point of worrying about anything else? They've got your CPU and so that's your host. You're you're you're gone. You're done but it's very easy in theory to Modify the for example the read-rand instruction on Intel CPUs So that it has certain biases now The biases are going to be hard for you and I to predict or to even measure But for the dedicated attacker who put them there. Maybe there is a secret key that lets them Distinguish the bias or let let's them you know, let's let's them follow the biases through say a TLS session and The same very dedicated attacker who can make a little tiny change to your CPU that you're not going to detect even with a microscope There's a paper just last year What was it CHES I forget with that anyway about how you could modify the See the silicon so that you can't detect it with a CPU, but some bits are wired to zero inside or something So an attacker who maybe can do that. Maybe they don't want to More broadly compromise your CPU. Maybe they don't want to add a bunch more gates in it that will leak information somewhere else Maybe they don't want to Make it you know leave tracks that will make it clear that they did actually compromise your CPU so at this point I would like to mention that When I started looking into dev random and dev you end up in net BSD about a year and a half ago I found that on free BSD On Ivy Intel Ivy bridge systems, which were the first ones that supported the read-rand instruction Dev random and dev you random both sourced directly from the read-rand instruction That is there were no other entropy sources involved. No matter how much you banked on your keyboard like a monkey That wouldn't affect the output of dev random. It was only from the CPU's random number generator I Talked to some free BSD. I talked to Colin Percival about this and and at the time he said well if they can compromise your CPUs And it's not much of an issue One year ago After some of mr. Snowden's disclosures free BSD reverted to using the read-rand as just one of several entropy sources so All right, so for the for the recorded audience you all just added that in there was a north bridge random number generator some time ago To which Intel applied a dye shrink and In doing so some of the diodes inside that were supposed to provide Noise that were supposed to provide entropy went away and stopped writing entropy So in addition to The the sort of mundane and not very uniform Entropy sources that I've discussed There are also various hardware random regener is hardware entropy sources on the market Now you can get PCI devices that you could add to your you know add to your workstation various systems on chip have Entropy sources on the dye And then there are CPU instructions like the Intel read-rand instruction or the via padlock instructions now I've never personally looked into how any of these physically work If you pay money for them you would hope that they work well to be unpredictable, but who knows I don't know So actually my favorite hardware entropy source you probably have in your pocket It is just a coin here And now if you are practiced you can make yourself reliably flip to heads or tails whichever you want But to all of you folks what I flip is pretty unpredictable and in fact, I'm not very good at I don't even know how to how to make it flip heads or tails myself so I Mentioned earlier you can write to have random and so you can act as your own little entropy source writing to have random Just provides entropy that goes into the entropy funnel and then is used to seed the PRNG and so if you if you want to generate a key that you're kind of paranoid about and you're confident There are no cameras looking at you So, you know maybe do it in your own bathroom at home or something and hope you haven't Tracked at the interest of a long-tentation state then just it takes I mean 128 flips if you know if you if you want a decent key If you're bored you can do 256 times. It's you know, it just takes a couple minutes And for a long-term key, you know if you want a key to last for 10 years without being compromised without being Guessed then you know maybe a couple minutes is worth that time so That's all about the Dev random and dev you random in general About a year and a half ago as I mentioned I started looking at the implementation in net BSD and Found a lot of things where I wanted to improve it So just a few little details of how it works in net BSD When you open dev random when you open dev you random You'll get your own per thread or per well your own per file descriptor state or per CPU state if you Just make small reads from dev you random, which is a little bit silly. I'm not sure that's the right thing, but So the point of this is that Dev random and of your end on net BSD scale You don't need to worry about Multi-processor issues that they're not you know if two processes reading from dev you random can do it on different core without interfering For generating key material for crypto Net BSD uses the NIST counter mode DRBG deterministic random bit generator synonym for PRNG pseudo random generator This is not the famous dual EC DRBG. This is one of the three totally reasonable Algorithms in the same standard Which it's not plausible to have been backdoored So it's it's just uses a block cipher in counter mode to generate some outputs and then reseed itself from the last output of the block cipher and we use AES 128 For non key material inside the kernel we use a much faster PRNG much faster a stream cipher cha-cha 8 This is only for Preventing an attacker from preemptively guessing what the output will be rather than retroactively guessing So it provides predictive resistance, but not backtracking resistance. So we don't use it for key material We use it only for like NMS transaction IDs Similarly the user land arc for random which Theo gave a talk about just an hour or two ago We're going to implement re-implement that soon with cha-cha 8 and Basically have it be More or less the same as the kernels fast PRNG Although I did some surveys and I I couldn't find any code that uses The arc for random API to generate key material If you know of such code, please let me know I would like it if there weren't such codes so we could just not penalize the code that doesn't need backtracking resistance But I would like to know if anybody really does use it for key material For key material as I said earlier if you want to generate a key use devu random I looked at open ssh and I don't recall what it uses to generate keys, but I'm okay I I had thoughts that open ssh used the open SSL PRNG, but maybe not. I don't remember. I'm not I'm not sure I see some people not shaking their heads so Yeah, so but the what? Yeah, so the question for the recorder audience is Well, doesn't open ssh use arc for random for session keys And york says it it does but only in the child process In the child process will have only one session Future child processes will be receded separately So you can't use their session keys or anything about them for total compromise of future child processes To guess the session keys of past child processes That's my that's what that's my guess right now, but I'm not sure about this so we can take this offline I discuss further so that's some That's it Use of your random any questions You mentioned the case of dev random blocking in the case when it has enough entropy How how does it know when to block and when to unblock in this case? so basically there is one of these little accounting trolls sitting inside the implementation of dev random and it Debits a little counter every time you read data from The entropy pool roughly is that traditionally works and once the entropy count goes down to a certain amount then it decides time to block This doesn't really have any physical significance. It's just the way it's traditionally done Personally, I would consider just having it flip a coin to decide whether to block Just so that your code paths get exercised and otherwise you're not led down a path of treating entropy like a Scarce resource like oil you can deplete So you recommend using dev you random what about the new sys call wasn't Yeah, so the trouble with the new system call or the new system calls or the new system calls with multiple flags or Which are different and different up the point is There are multiple proposals floating around right now one implemented an open BSD one implemented Linux net BSD has a sys cuddle node that you can use to Grab entropy and that's how Yeah, I've previously to that's how arc for random and libc seeds itself doesn't use dev you random That's all going good. But right now if you're running an application You can make it, you know like four lines of code to open dev you random and read from it rather than 60 lines of C preprocessor to detect what operating system you're on whether it has dev you random plus the autoconf stuff to decide we're whatever else so You know soon enough, maybe there will be a standard library call that we can all use for generating key material, but Right now I still say use dev you random just a comment There's a move to standardize arc for random or some similar variants in posix now. Oh, okay I had not heard about that I missed the oath talk. I'm afraid more questions So one of the big problems with death you random as you might know and to did mention that is that basically you can be in change route or Use Capsicum in free BSD which we use more and more now so Using global namespaces to actually locate the random device It is a bit problematic. So CTL is much better solution for now or some dedicated system call for that Yes Nevertheless, I think right now It is much easier for most applications to get by using dev you random and Is what what you said about four lines of code? I think it's much complex than that because sure you also have to Handle the case when when you cannot open the front of men what to do next well, then you fail which abort crash Not if you are in a library, so it does complicate. Well, what happens if the system system call fails It is much easier to make it impossible to fail or the system called to make it impossible to sure But understand the portability Argument of course. So yeah I mean, I think that it would be good if if we had a system called that we're simpler than a standard library routine That we're simpler than dev you random I think that sounds great, but right now that's not there yet and So Another question Because as far as I understand and from what I saw from some previous discussions When you guys designed all this is that you have two kinds of randomness Faster and let's say weaker and yeah, that was the the flow CTR dbg with a yes versus the fast judge, which which I also find a bit controversial because You pass the burden to the application writer to actually decide which to use and of course I think that the better move is to to remove such a burden from application writers because because Honestly most of them have no idea which one to use. Yeah, that's that's that's fair. I don't disagree So you should create one AP. Oh, yeah, this is this is these are just just within the kernel I So with for user land programs dev random and dev you random it's it's all that all goes through the AES CTR drbg that's all goes through the the slow one that's fit for key material Yeah, I agree that using the counter mode drbg is a much better idea But I have written applications that use millions of bits of entropy and a yes 128 bit CR CTR is very very slow when you're consuming millions of bits Yeah, that that so that's that was that motivated the choice of cha cha 8 which is very fast And even in very naïve C code and has a very low footprint just did you know a couple of cash lines? So you can distribute it across CPUs Thank you, and why cha cha and not cha cha 20. It's a lot faster And currently there cha cha 8 remains unbroken to the best of my knowledge So cha cha 8 you can compute 64 bytes of output in about 300 ivy bridge cycles on Using naïve C code Cha cha 20 takes a good deal more. So did you discuss with open bees the guys why they choose cha cha 20? Nope I will not repeat yogg's a pointed comment about open VST for the recorded audience Any more questions? Okay, thanks. Oh, thank you. Oh, yes, and there's a fun little entropy game on the website to As an instructive exercise in why you should not try to come up with your own passwords or flip a coin in your head So this is this is the password manager that I use