 Our next speaker is Aaron Sauna from Austria Security Consultant and he will tell us about random generators. Random is very important in most cryptographic things and there are some things that changed in the last years and he will provide an in-depth update on how randomization and generation of good randomness will or should happen in the future. Please give a warm hand for Aaron's honour. Hey, so originally I was supposed to give the talk like yesterday at half past seven in the evening so some of you maybe may have been there and expected to see a talk but I moved the talk around to today because I didn't sleep the whole night before that I'm running the scanning project here so we're doing live internet wide scans from a machine that is connected via 10GB and Nick Farke convinced me to do that so if you're interested in that you can send a scanning proposal to ShahScan at rsetet.org or just look it up in the wiki from Shah and participate in that we already had like for around 30 scans with really cool stuff upnp, stdp, s7, different gprs protocols that run over tcp, rdb over converged ethernet and stuff like that so just to fill like this a bit more because I don't have enough slides to be honest okay so I'm going to talk about random language generators in operating systems and in programming languages there is this really well known blog post by Thomas Patschak that just says use u-random everywhere and in general he's completely right, Filippo Valsorda also had a talk that was pretty similar and was also like kind of based on discussions between Thomas and myself if you're on linux that's that's totally fine and you should do that or whatever your language provides but I guess a lot of you are developing software that will be run on other operating systems as well so that might not be the only option to use or not the correct way to to go so that was the reason for the title of this talk I don't have a table of contents perfect okay so why do we need random numbers I think for most of you this is pretty pretty straightforward we need you need to randomize stuff in your operating system your scripts your programs whatever for example there is a rant function from open from the open message library which you should not use by the way I'll come back to that later on if you're using python you can use osu-random which will depending on how you call it give you random bytes it's for example commonly used in transport Leo security so in HTTPS to randomize session cookies or session tickets sorry cookies and tickets are different things it's obviously used for key key generation so if you're generating an rsa private key you need to have two large prime numbers which you choose at random right and then do a primarily test on it same thing for diffie helman so you need fast random number generators in modern operating systems and languages because some of them like for tls if the random number generator would be slow the whole application and the whole stream would be really slow because everything depends on the random number you cannot send another tls it's not called packet tls record if you're if you're still waiting for your rng to output randomness right so for example there is a rng in bash it's not really good but you can you can use like the random thing and it will output a random number don't use it for for real security stuff by the way it's just a just a hint so cryptographers like to call random number generators cryptography secures you to random number generator most of you will just call it an rng or random number generator but if you're talking to academics or cryptographers or security engineers they'll probably refer to as zsp rng and that's what they that's what they usually mean by it that's a secure random number generator based on secure cryptography so um csp and g's are widely implemented in operating system kernels obviously um the most commonly used one in linux is def u random it's the random char device in the linux kernel um there is a man page called sorry man for random not man random um that has been wrong for the last 10 years it has been fixed last december finally for example many of you probably recall that there is a short paragraph in there on how to read the available entropy in the system um the um yeah how much entropy is available and how much entropy you're losing losing or something like that these values had no practical uh implications and actually by just kernel internals you couldn't do anything with um but the man page wrongly assumed that everybody is going to read the man for a rampage uh random man page is going to be knowledgeable about the linux kernel and linux kernel interest leaks about cryptography and how the uh random number generator itself works which is very complicated by the way um or used to be so i don't know why it doesn't show the first thing but uh free bsd um has a random number generator where you can use either def random or def u random or def whatever random um it will always fall back to def u random this sim link as far as i remember um right now it's based on um a stream cypher xr construction with um asni instructions if your cpu supports that so if you have a modern intel processor or modern amd processor you will have an rd seed and rd rent uh um it's called uh instruction sorry um which will then um at 10 gigabits per second or even more output randomness from the from the from the um uh central processing unit itself this output in case it's it's malicious or in case there is like a bug in the cpu will be xr'd against the stream cypher in this case is chacha 20 by dj Bernstein um they recently had a bug uh yeah on april 16 there was another improvement replace the rc4 algorithm for generating in kernel secure random numbers with chacha 20 so that recently happened rc4 is still in there because open bsd that's like the classical open bsd construction for um uh the random number device so there would be like um either a pool or something like rd seed from an asni instructions in the cpu xr against a stream cypher which used to be arc4 um they changed that with chacha 20 they already did that in open bsd years ago obviously um but yeah who uses it anymore sorry guys in windows there is a couple of ways you can um get random bytes um usually it's i think uh crypt random or something like that but for that you actually have to load a dll um if you use rdl get random you don't have any dependencies um this is what lip sodium for example does which is an awesome cryptography library if you're doing anything in that direction and you want an abstraction for getting random numbers just use lip sodium or um a lip sodium binding in the language you like like there's a binding for python for ruby for pearl um i like lua for example there's a binding for that um in programming languages obviously you have bindings available to these as i just said so for example in python you have us u random in phpu frand which is broken by the way um they're trying to fix that function in php6 as far as i remember um um there's a guy called scott with a long last name polish one um i cannot pronounce um he's working on that um together with uh solar designer which some of you may know from the return to lip c attack and like all of his cracking stuff um yeah um some of the languages had really really bad bugs for a long time uh one of the really cool examples that everybody of you will know is the 2008 bug in the in the ssh key generation in debian so you had predictable ssh keys for years there's a small tool on the internet that will just take a public key from an ssh server and tell you if it's a if it's a compromisable key from that period it was fixed back in 2008 but this is one of the things that many people still go back to especially when they run about open ssl right because they were using open ssl for for the key generation and a debian maintainer ran well grind on a function in the random number generator and tried to fix it so yeah by accident he buys the output of that function uh wait why is it going to sleep no it's not my laptop um yeah by accident he buys the function trying to fix a memory leak um uh and thus you had predictable ssh keys in all of the debian instances back then um it's a long time ago but some of you may still have legacy machines lying around in some data center that may be vulnerable to this like if you do security consulting uh usually usually look for these keys and uh usually find one or two machines out of like three or four hundred that still have vulnerable debian open ssh keys because it's some legacy machine that somebody set up kind of left the company it's interconnected to other systems if you turn it off no but nothing works anymore and nobody knows how to administer it like the standard consulting problem we have in austria at least sorry many use the kernel provided uh csp and g others use open ssl or custom random number generators this is bad don't do it um i'll come back to open ssl a bit later um open ssl provides a user space rng that many many programs linked to for example back then open ssl's hd they nowadays use something different um from the top of my head i don't know what to be honest um and recently there was a nice uh bark like that was two weeks ago gcc generates incorrect code for rd rand rd seed interesting intrinsics um yeah that's a bad bark it's it's hard to trigger but yeah this would be an example of a thing that can go wrong in the user land if you develop c code and are trying to either implement your own random number generator with rd rand rd seed or if you're linking to another library that doesn't do that properly for example open ssl would be one of those open ssl is perfectly fine for tls but if you use a random number generator or a neat random number generator for a use case other than tls please don't use the open ssl or um some history so um the def random and the free random devices have really really old code like the first time i looked at the code base it it recently changed yeah i know i'm coming back but um it's really old code like when i first looked at it was four or five years ago most of the commits except for really small one-line documentation commits or typos that were fixed in a code were from like 1992 1994 and 1996 something like that um it's it originated originated by uh from tetto one of the also blocked level developers in in the linux kernel who also um designed cabaret version two for example and a lot of other things so he's knowledgeable about cryptography quite a lot but he's very how should i say this in a nice way he's very like his way is the right way and you it's very hard to convince him of doing something differently and um with subsystem maintainers in the linux kernel that's very common as some of you may know who who reads like subsystem mating lists um changing some specifics that somebody worked on for a really long time may just not happen even if you have a better code than they do um as i said before you don't have to worry about kernel entropy anymore you never had to worry about it and that's the actual problem about the mem page that that i mentioned earlier on um it's a myth that you have to uh read out what the kernel has on entropy by the way it doesn't do that anymore um and have g h e or the have h d man won't save you at all like people come to me and and and always ask me if i use have h d and it's so awesome then i ask them if they read the original paper which is like 10 years old and assumes spark was it spark four machines and some some interest sticks about like these cpu's it will work on x86 machines but there is far better ways to to get good entropy and good random number generators than using like a really old user land um demon many many people do that i know um and i want to get them away from that because there is potentially entropy attacks so people like did you burnstein wrote about this in his blog a couple of years ago in 2014 um so in theory you can bias entropy in a way that you as the person that is biasing it um can then calculate either a seed or the actual from the seed the actual random numbers that the rng is uh giving to the end user or yourself um so as have h d obviously the user land program it's easier to exploit it because you don't need a ring zero exploit for that um and adding entropy to a system depending on the quality of the entropy um might actually make the random number uh the stream of random numbers worse or better there is like this old myth that if you um add more entropy into a system and this has nothing to do with thermodynamics by the way and that's what many people i think mix up in their heads um if you add entropy to a kernel um random number generator it's just going to be better it doesn't matter which kind of entropy you add you can do a cut death now and and and write it to you random and that's going to be fine no that's not the case you can actually bias the random number generator the only reason that doesn't work in linux is because they thought about that about um users in user space doing bad stuff yeah um so the old linux kernel implementation from like ancient times until four dot two um used it's really difficult code to read there's an academic paper on it and a quite nice blog post by erran top nonce um so if you're not into reading academic papers i'd recommend just reading the the blog post it also has a newer blog post on how the linux kernel random number generator nowadays works that's one of the best def read um there's also an academic paper of like 20 pages that explains every single pool and mixing function in the in the old random number generator so that's the def random and def u random device where def random is non-blocking and def u random is blocking ah sorry the other way around def uh random is uh blocking and def u random is non-blocking um um yeah it's quite complicated to understand even for well or cc programmers we saw that in a couple of bugs i opened in language implementations and their use of uh kernel rngs or the operating system rng they tried to understand what's going on there and even though they were like language maintainers like people that wrote for example the the core code for ruby or python uh python is not affected the core code for node js so c++ or um ruby that c um didn't understand the code that i was sending them and it took me also quite a while to understand it because there's just a lot of mixing functions in there that the bitchifting and sorry and and and stuff like that and it looks like a cipher design but it's actually just trying to mix interrupts and information together um as far as we know the the old linux kernel implementation of def random and def u random work without the large incident i'm not aware of one if anybody is please come up to the stage um but that worked i guess out of pure luck because if there would have been researchers that were really trying to attack these mixing functions we recently looked at some that were um um taken out of the kernel code um some of them would have been maybe uh exploitable but like in a really um minor way so you couldn't probably influence what um um random numbers of for example userland program gets back um but you could influence i don't know maybe tcp copies or something like that um so there's a curiosity um jason donoffel of why i got sent me by the way of why i got stickers i have to spread out it's not stickers so there's stickers here if anybody wants so why i got is this new cool in kernel vpn um that jason donoffel wrote um with uh mainly algorithms by daniel Bernstein and jp omason he implemented most of that he's also working on redoing a lot of the crypto implementations in the linux kernel right now so like two weeks ago uh jason and jp omason um implemented sip hash as a replacement for md5 in the linux kernel um because md5 is used everywhere in the linux kernel for hash tables and stuff like that and obviously you can gather hash collision if um you have a system that is big enough there is this story he told me recently on a slack channel um he came across this fast mix function i'd really like to show you the code can i do that here is there internet here i have no idea wait a second i don't know how the system works um doesn't matter just go to tinywool.com uh slash fast mix um um there is like this code but this guy called jord spevelin spevelin um that wrote it like 10 years ago this guy is not a cryptographer apparently he was involved in seismic measurements and earthquake detection and for some really weird reason he wrote a new mixing function for the for the random number generator in the linux kernel which is by the way still in there so jason is trying to get it out of there um right now even with the new you random design this mixing function is still in there as a backup or fallback i'm not sure if it's used by default i don't think so but i'm not sure i would have to look it up i think that's like nice trivia to have um so the current implementation of the of the um rng in the linux kernel um it took years to discuss the tetsuo and a couple of other people of the original authors of def random and def u random um about a new design for the random number generator in linux it's all in uh drivers char random dot c um but after like a year of discussion and a german guy that wrote a pluggable interface for different algorithms or stream ciphers to be used in in random number generators and the 100 page white paper they decided to actually uh change the current implementation um the current implementation is also a one based uh written by that tetsuo but um it's largely copied from what's boring ssl does so if you if you never heard of boring ssl um boring ssl is like google's fork of open ssl and so what they did or what basically adam langley and a couple of other people from the chromium uh chrome security team did was fork open ssl at a certain point and then ripped everything out that was senseless and rename all of the function names and the intentation scheme so you can actually work with it um then they uh got rid of all of the tests that were written for open ssl and rewrote all of them in go um so if you want to use it it actually works but it has very limited capabilities so it's it's nice to use as a tls library but you cannot use it like open ssl in a general way so say i want to use triple des for some weird reason and i want to link against uh libcrypto that won't work with boring ssl but if you want to use it in a tls implementation it's really fast it's really nice um and what tetsuo did and adam langley before him um was to decide okay we we're going to to see which architecture we are on if we're on a modern intel or amd cpu and executing there um we have rd rent and rd seed instructions from the asni extensions both uh intel and amd cpu supported by the way it's not only intel some people think that um and then we're going to get um a seed or entropy from uh esni via the rd seed instruction and xorid with charger 20 a stream cipher that is known to be quite good and non-reversible um so that's a neat design it's backtracking resistant as well so um if you get the um the output of a random number at some point you won't be able to even if you get the seed at some point the original seed to um go back in time and calculate the random numbers that the rng was outputting at a certain point in time that's backtracking resistance in in like a few words it's a bit more difficult so i just ran this thing uh on a server of mine um so with block size one megabit megabytes you get like 90 megabytes per second and it used to be 10 megabytes per second and depending on the block size it gets even faster obviously so that's the current implementation um from 4.2 on i think at 4 to the 11 on this machine sorry um there's also other major work overhauling cryptocode in the kernel started with linux 4.2 it doesn't only affect the random number generator as i said chasen donnerfeldt the guy that writes wire god is also involved in some of the the work there and as are many of the original developers so they are trying to like get md5 out of everything and write cleaner code that other people will understand they added backtracking protection to the um charger 20 based um uranimate implementation there is a link there i'll put the slides online afterwards so you can click on them without writing it off to the screen um so this is what petso wrote uh wrote on uh june 13 2016 last year with def u random we were always emitting more bytes than we had entropy available because not blocking was considered more important previously we were relying on the security of char one with a ctr dbrg which is a deterministic random bit generator uh you rely on the security uh with a s and that's fine um um so yeah the entropy thing is basically also um gone um as is this from the main page and uh they also have a committee in there that um disables um for example that you can um get uh uh to a cut on proc entropy available or something like that these interfaces just don't exist anymore in the proc fs file system um they were taken out because people were using them the wrong way and um wrongly understood what they what they meant or what the impact is of like having low entropy like a system doesn't run out of entropy it just doesn't work like that um embedded system maybe um so there is another patch that replaces you the uranum pool that was used before with the new random number generator um a blog post uh post from nicoz marie ganopoulos who is the gnu tls um core maintainer i know i shared this uh this opinion um to their defense they will have to provide a call which doesn't make applications fail in the following scenario crypto ssl libraries are compiled to use get random the function call because it is available in libc and in the kernel um everything works fine the administrator downgrades the kernel to a version without get random because his network card works better with that version mayhem as application fail applications fail this actually happens um in live production scenarios and he's very right about that you should use the get random call if you need uh if you need randomness in your application or whatever your your scripting language or um programming language um provides you in its standard library but um get randomness like the the future thing to use but current libc like if you if you use a db and stable version the libc unit won't have the this function call so you cannot use it um same thing for retards sent to us fedora and like i think uh it's also not fixed in gen 2 which is great um i think that the only uh the only distribution that has get random everywhere in all of the different branches is arch Linux but i'm not really sure about that don't take my word for it um they also had an another nice patch for numersystems so on a system with a four socket uh on a system with a four socket numersystem where a large number of application threads we're all trying to reach from def u random this can result in the system spending 80 percent of its time contending on a global u random spin log the application should have used its own prng but let's try to help from running lemming like straight over the uh locking cliff whatever the last sentence means so that's also a post potato um so they were fixing uh no more topology things um and improving the performance of def u random um if you're using the open messes at rng that's that's a uh nice to know on the side it's not a threat of fork save so if you use that rng and fork for example um yeah you will get uh predictable random numbers um so the myths myths and lies of man for random are finally corrected this happened in i think the late december of 2016 so last year um the guy that maintains the linux kernel documentation he wanted to change that for years because he knew he knew it was wrong um but the actual implementers of the of the uh random char a char device like a um protested against the man page change um what was in this man page had a huge impact on random number generators used in programming languages i'll come come to that right away so language issues ruby it's like one of the one of one of my uh one of the things i got famous for on hack and use for like screaming at ruby core developers and um like did this buck report that is some somewhere down there i even i even printed a t-shirt um so in ruby if you use um ruby provides a random number generator which just doesn't work and there is one that every proper ruby program programmer uses that's called secure random where the s and d r are capital letters so if you want proper randomness you would think you would like um import or require in this case or it's python versus ruby require secure random and then you get random numbers this is in general would be true except if you have any buck in open ssl or in open ssl's rng implementation or in the way they call the rng implementation in open ssl for example if if they would use threading or a fork it wouldn't work um out of luck that wasn't the case but i also didn't have time to to look for writing an a proper exploit um so in this buck reported this is like the legendary buck mentioned down there it's like me um tony rh area who wrote a wrapper for um secure random later on so you could just call sys random and it would use the operating system rng and uh wrap around secure random um filipo valsorda who also had a talk on u random a couple of proper cryptographers uh yeah myself trying to convince the ruby core team to change the use of their uh random number generator and how they use open ssl and like i wasn't ruled in the first place later on yes i have to be honest um but i saw that there was an open buck for like four years that said please change the implementation of your rng but by some guy i've never met i never posted in the thread again so i picked it up and said like guys this is actually important i work on exploits in this direction you should fix this i used to be a ruby developer um so i would would have to like this fixed um it took like two months and then some guy in really bad english wrote back no i was asking why um and basically the answer was yeah because open ssl is very good like if really read that buck report um it's really funny what some of the comments are um like some of the comments i wrote on a printed on a t-shirt and ordered by like coffee press um so yeah um in reality it wasn't properly implemented and it took like four or five security engineers two of them proper proper like phd's in cryptography and mathematics like a year to convince them to change that and what made them actually change it around was this thing the man page was changed upstream and then they agreed to change the implementation because they were relying on the man page and they were always referenced like in all all of the arguments they made in in this buck report they were referencing the the um you uh random form man page from linux and said like this is the way we have to do it it says in there like pasted them code from from the implementation like no it that's not really how it works you can read c code please try to understand it and then i posted like 10 or 15 academic papers with um how the random number generator actually works in linux and with which attacks are possible on the open ssl rng um and they just didn't care you can come up with it could come up with the best arguments even with the working exploit and they wouldn't change it but when they finally when linux finally changed um what's in the man page of um uh man for a random they were actually convinced to to change the implementation so what they're doing now is use a similar design to lip sodium um if you're not familiar with lip sodium um it's a really nice library and there's wrappers in all of the other languages for it um by frank danis um so lip sodium basically looks okay on which platform am i on on which operating system am i on and um do we need random numbers or bytes that's just different function core and then it decides if he's if he uses the few random um rtl game crypt or what it was on windows uh i have to look up wait yeah on windows it's rtl get random um and so then they decide on the on the best way to to get randomness from the operating system not from user space and that's the way you should actually do that and ruby now does something similar except that they don't just link in lip sodium they copy and paste it some stuff from the open bsd kernel and just use that i don't know why um but it should be fairly fairly okay now so yeah some of the statements were like secure random without open ssl or compatible alternatives is nonsense and i gotta please don't root very often uh from the core developers um there's a similar a simulation is in open uh sorry in uh node gs um there is like this really long bug report if you open it up um the github issue is i don't know if you if you would print it out on a4 paper it would be probably like 20 or 30 pages um and it's mostly people that are using node gs who have no experience with with uh crypto engineering or with cryptography or with security in general it's just normal node gs users trying to i don't know impress core developers in the in this bug report or like say what they have to say and it's like an endless thread of people just posting nonsense there's nothing to do with the actual security issue um the latest comments uh was while i was here so i had to change the slide um this is from like two days ago a guy uh wrote like note that open open ssl has just landed a commit to use the dr bg with with a ctr from nist sb 890a it's like the nist uh special publication um for uh random number generators i think and they have a recommendation in there which um how a random number generator design should look like um by default defined flag of open ssl rand c os i think it's best to wait for us for the next release of open ssl 111 um a quick note about that like the way node gs actually um links against open ssl is very weird they have their own fork of open ssl in the code tree um so they forked open ssl at some specific version and then put it in their own cope off so if you go into like in the in the code of node gs and go into source external or depth or something like that you will see an open ssl directory um with an unknown fork and they even changed around the version number um so everything that that open ssl changes they have to reimport somehow um obviously if there is a buggy in the code they forked at some point um they won't get the updates from upstream they'll have to find out about that somebody has to notify them and then they have to fix it themselves themselves by hand they don't only do it a bit open ssl they do it with a couple of dependencies node gs has um yeah like it's node gs it's not the proper programming language don't use it like single file applications are shit seriously though like there's there's really large web companies that use node gs as microservices and run it everywhere and then they're wondering why they're maxing out cpu's and like I cannot call an uber why because it uses node gs that's true by the way um so the same issues um exist in Erlang I didn't have enough time to finish this slide to be honest um because I was busy with um scanning stuff um same as in ruby and in node gs um there is except there is no discussion going I opened the bug report about it I think a year ago um I don't think anybody replied to it um the implementation is exactly as it was in ruby and it is still in node gs um they just use the open ssl uh user space random number generator so that's also an issue and if you want to look for more languages to do that I'm sure more languages do that um python is not one of them by the way um python does the proper thing um and uses u random or depending on what operating system you're on the correct function call on windows for example um if you want to find out more languages that actually have this issue just look at the code base and find out where like the crypto stuff is and somewhere there will be a random call like if you go on github you can just enter random and then you'll see how it works and I'm sure there is more languages out there that that um have either a broken rng they implemented themselves or um use the d open ssl one which they shouldn't use um so there was a python improvement about insecure values for big um big amounts of data from from secure random in python 3 6 or something like that that was only an improvement it's not really an issue or vulnerability or a bug as I said python does the correct thing and uses um the operating system kernel random number generator so um what's the issue with open ssl again just to reiterate it's not threat a threat safe it runs in user space um it's as we know it's prone to bugs and it's especially prone to bugs in code paths that people rarely look at so for example after hardly people started to look at open ssl really hard the core team was extended by four developers two of them paid by the open ssl foundation two of them paid by google so the actual um open ssl code is quite nice nowadays if you look at like a a current version um it has even a proper intentation scheme and function calls are re uh renamed um to be obvious and and open ssl really improved after hardly then there was one of the really nice things um but what researchers in academia and also in in like on the in the blackhead scene and exploit development usually do they look at obvious code paths like tls can i can i uh hack some bug in open ssl that I can decrypt traffic because that's interesting right but most people don't really have a lot of knowledge about random number generators how they work or how to exploit them so that's one of the one of the things in open ssl that even the core team from open ssl themselves hasn't looked at for a long time as far as I know like I talked to a few people from them I was like yeah like hand wavy I'm not exactly sure how it works and what it does in this in this specific case so I'd rather not use it if the core team doesn't know how it works um there is this like wiki page from open ssl themselves and an issue on on on the topic to change what open ssl uses um to the operating system provided random number generator or what like lip sodium does so depending on the operating system and architecture um do something um specific um but if you go to the wiki page of um open ssl to random numbers it clearly says don't use a random number generator so yeah I have no idea like and this is one of the things I posted the ruby guys like on the wiki it says you shouldn't use it yeah but what what what else to use we don't know so they didn't change it it was really annoying I was really pissed off um yeah like all of the people from open ssl I talked to were not aware how it really works internally and how secure it actually is but because there wasn't an audit on this part of the code like most of the tls code is very well audited because um companies like google and security consultancies like ncc group uh regularly audits uh the tls part of the of the system or um um or specific function calls that people often use for example open ssl come open ssl functions that would be linked into and used for filing encryption in some tools or I don't know these these are things that are usually well audited and nowadays are kind of safe to use and I don't know about the library to use instead of open ssl to be honest like there is a really nice tplus plus library called botan but if you're stuck on c I'd stick to open ssl. Libre ssl is just shit and boring ssl is only tls so uh yeah half ghe um like I'm on this crypto meeting list for like better crypto and we have this large document we wrote in 2013 after the snowden revelations on how to properly configure your services, routers and um software demons to use strong cryptography and like every four months there's this guy who comes up or like this person is always another person and asks about rngs and why we have half ghe in there because somebody added it to the document um so I removed it from the document and said to everybody should use lip sodium or the kernel random number generator if they're on linux 4.2 upwards um and obviously it started a big discussion like people were arguing half ghe they have used for years never had a problem but then again they also never looked if they had a problem with it um so one of the people in the discussion actually made an effort and wrote to the guys to the original developers of um half ghe the algorithm and the implementation it's both um designed by I think ens in Paris ens or in ria in Paris I don't know ens or in ria um and from like five people he wrote to only one responded because he still had a working email address there this guy told him uh yeah it should be perfectly fine but by the way I haven't looked at the code in 10 years and this is like the core developer um there is no security analysis of half ghe except for the should I write pussy so uh yeah there is no like in the original paper for the half ghe algorithm there is a security analysis obviously if you implement the security software or an algorithm you should do a security analysis in your own paper and then wait for a crypt analysis or security audits by other parties for half ghe that this never happened like nobody ever audited the code the algorithm itself um and as far as I can see like in the code it's really old c code it uses intrinsics from as I said old spark machines um for entropy generation collection um which obviously if you're not running like a spark 64 machine anymore which on dvn you can't because it's a deprecated architecture and I think only three bsd support it anymore and that bsd open bsd um it won't be better than what you have on your system anyway and like with the blog poster linked to earlier the entropy attacks that Daniel Bernstein mentions it would theoretically be possible to bias your um random damage generator if you use half ghe and exploit a bug in it so that like the randomness that half ghe provides additionally to the system random number generator would be malicious so you can actually do really bad things with that and it runs in user land it is you don't need a ring zero exploit to exploit this stuff you just need to look at their c code and you see that it's like really not that good it's it's nice academic code but it's not a proper security code that would use an operating system it's not developed anymore and they don't they don't ship any updates to the code um as far as I can see even from people that's wrote like they don't have a bug tracker or a security address it's like a page that says half ghe and this is a research project from 10 years ago so obviously it's not maintained like an open source project it's maintained like like a scientific project that somebody did for their phd thesis or their master thesis um so there is no way to send in bug reports and even if you want to do that you have to find out like this one guy has still a working email address out of five to five of the core developers and then he doesn't change the code anymore so I have no idea how to get a bug fix in there if there is something to fix for example I wouldn't use it and I removed it from all of the documents that other people wrote and um sent me yeah parting words I don't know it was like the slide I wrote when I was running into it um so yeah um what can we learn from that um usually the the operating system provided random number generator should be pristine and very good death being obviously problems with that um a really well known problem is like three or four years ago free vst decided to implement something similar as linux just did and use um the asni instructions if they're on amd64 um to get um high bandwidth um randomness they somehow fucked up the code and uh got uh biased random uh biased randomness out of that and nobody noticed it for four months it was in in the current tree I think it wasn't in a really it wasn't in a release but it was in the current tree and people run that so uh yeah they had data like uh yeah a biased random number generator for four for four months in free vst so that happens but it rarely ever happens it's like the only time it happened during um since free since the inception of free vst for linux I'm not aware of any any instances like that only of user lands issues like the db on open messes at debacle and um other open messes at rng problems uh windows and solaris for example I have never heard of any issues with uh with random number generators solaris had a we didn't have a random number generator up up until a certain um sunOS version so you had to write your own scripts to get open messes each working I remember that from like 15 years ago but if you run a current solaris or ilumos or whatever um operating system this will work just fine so yeah thanks do you have any questions I think we got five minutes so yeah thanks for your talk and we do have some time for questions but please keep the questions short so we can fit as many in as possible go ahead please would you be so kind and switch on the microphone okay test test um you said you shouldn't usually wait a second it has to be in the recording as well right so we have two microphones for questions in the hall so you could also try the other one let's see which one works first and that one that version then gets to answer gets to put the question first I could just give him this the microphone for a second I guess is mine working yeah okay is it no it's it's oh now it works okay uh you said you shouldn't use Libre SSL why is that ha I knew that was the first question so like I'm originally a free bsd guy I really like bsd but let's be honest most of the people run Linux nowadays most of the enterprises work at do I'd really like to deploy more free bsd machines for example but usually gets declined the problem with open bsd projects is like they have a project for everything there is like their own implementation for ntp their own implementation for pgp their own implementation for everything basically because at some point they figure we can do it better and mostly they are right but with a project like Libre SSL like there is vulnerabilities in Libre SSL that are not in open mssl and that's just because of the way they were treating the code base they were just like this is shit we are ripping that out this shit we're ripping that out without knowing the history of the code and in open mssl although the original developer is called lei that's why some of the function calls are called slay although he's not working on the project anymore there's people in open in the open mssl core team that has been around for 15 to 20 years so they know the history of most of the code part at least at some in some spare room in their head if they remember it's a long time ago right but um so there is will be the least that only Libre SSL is affected to they sometimes don't import um upstream changes from open mssl that really makes sense and I have no idea why and it's two guys so yeah thank you for this answer uh will you like to ask the next question please I know like a couple of other projects where it was two guys and it was one guy and five years later it was un-maintained and it was an open mssl project like open ntpd for example okay so you said that uh new version of the Linux kernel lNG doesn't count the entropy anymore um but did I got that correctly yeah yeah uh but this is fairly important uh oh well it is in the beginning so we had the paper like mining your ps and q's where we had the problem that all the embedded systems don't have a proper source of randomness oh sorry for not but exciting paper by the way yeah but we had so I'm just noted I'm not involved with the paper I just know it I read it but there was another paper that this also affects um desktop computers because a lot of the keys are created at one time before the user presses the first key so when the system doesn't have collected a sufficient amount of entropy so I agree that once you have a sufficient amount of amount of entropy that doesn't decrease by extracting random numbers unless you have a flawed lNG but you need to achieve a certain amount of of entropy before you output your first random number and that is the critical uh thing you need to maintain so this is totally correct I really like to see the the paper on the desktop environment because I cannot think of a scenario where desktop wouldn't have enough entropy at full time but especially with system deep but that's a different story um there's a there's a bug uh where they had to change uh you random code because of system deep by the way I forgot to put it in there um so for embedded devices this is totally true yes and it's an ongoing discussion on the Linux kernel meaning is how to deal with that because basically it's up to the designer of the embedded board to figure out a way to give interrupts to the operating system so it can like collect entropy if there if it's like a uh an embedded board without a real-time clock and without a network interface how the fuck are you ever going to get entropy that's like an open and unsolved problems as far as I know I do a lot of embedded development on the embedded board you have a lot of entropy sources you just need to use them and you need to they are different on every board yeah but can we have the discussion after the talk and get back to you with the other paper yeah this is something where usually the embedded developers would write the kernel patch and send a new driver upstream to the kernel and then it would work but yeah I've been I've been using uh dvbt dongle on an arm board to speed up airsa key sorry coming in I didn't understand I've been using a usb dvbt dongle to to counter extra uh radio entropy on an arm board to create the initial airsa key for the device uh I just understand adding extra entropy was a bad idea uh would you elaborate that on that a bit more like without doing a proper hardware audit and software audit of the sdk that the um the usb sdc uses I cannot tell you if it's actually improving your entropy situation or it's making it worse I don't know but it's radio waves right so radio waves can be externally influenced you just need like I have a u is a p at home I just need to know the frequency um your usb dongle is capturing at and just replay traffic all of the time then it's going to be the same bits right might be an attack that would be cool but yeah if it is properly implemented in software it won't it would just discard similar bits but I don't know I don't know the usb dongle but there would be a cool attack to pull off so thanks a lot for this talk I don't think there are any more questions I believe Aaron will be around so you can discuss your questions or have a discussion with him about some of the stuff he enlightened us about please give a warm hand for Aaron