← All talks

Rock Salt: A Method for Securely Storing and Utilizing Password Validation Data

BSides Las Vegas42:58203 viewsPublished 2016-09Watch on YouTube ↗
About this talk
Rock Salt: A Method for Securely Storing and Utilizing Password Validation Data - Arnold Reinhold Passwords BSidesLV 2016 - Tuscany Hotel - Aug 02, 2016
Show transcript [en]

thank you all for coming out and not taking a nap after lunch um you know as as I've been mentioned I've done been doing various things over the course of the last couple of decades to try and improve uh password usage I start off with a I actually posted something to s. Crypt asking people to send me their pgp passwords on a postcard on the theory that you know don't put any identification any identifying information on the postcard and quite a few people did and I put out a little survey and sure enough most people were making really weak passwords uh diceware hex is a uh I think one of the earliest probably the earliest um

memory intensive hash and uh um diceware um doing very well people have on their own translated it into a number languages the the the instructions and there are currently uh diceware word lists in 17 different languages how many people here are familiar with dice were I've seen it or how many use it right that's far for the course okay um another little thing I did was this is a a dice where uh we're taking a random set of 10 C 10 uh letters and producing a sentence there's a lot of password advice to take a sentence and make use the initial letters as as the password the problem is people are not very good at coming up with random

sentences and the the distribution of letters at the beginning of words is not that random uh this guarantees it's all uniformly distributed and any any any 10 characters you want you can get a sentence out of it to to help you remember the password um it's not my day job um I've done many other different things um I've also among which is I've written the security chapters of a number of different dummies books including email for dummies um it turns out when when Hillary had her 50th birthday she she got a copy of email for dummies from her staff uh I'm not making this up it was reported at the time and time in Newsweek um so that she could send email

to to her daughter who was going off to college so anyway it's all my

fault okay so today's problem I keep looking I have the thing in front of me I don't to keep looking at this the screen today's problem is protecting passwords in the Enterprise um what I'm talking about today rockol T is intended to Target Enterprise scale systems big systems many users server Farms e-commerce you know serious serious value at stake I'm not there's a whole other class of passwords that are used to generate more or less directly cryptographic Keys uh the pgp and GP PPG use it um dis encryption systems use it Wi-Fi um and password managers and Bitcoin wallets in those cases you know I I still say uh you know pick systems that use good key

stretching uh use diceware and contrary to a lot of advice write your password down because that way you'll have you'll pick a password strong enough to remember it and and no don't put it on a Post-It note next to your screen okay so back to the Enterprise which is the topic here um Enterprises have a problem they have to store for every one of their users some information uh that can be used to validate a password when it's entered into the computer and uh although many people keep talking about the death of passwords they not going any way going away anytime soon um the Enterprise can do things like throttling how many online login attempts happen per uni

time but uh there's this whole problem of offline attack um the difficulty is that databases that are in use are very hard to protect uh the databases are frequently stolen and uh just encrypting people say well just encrypt the passwords I think as most of you know it's not that simple um there have been many database breaches here's a few that I there's a list of them on Wikipedia um you know companies that should know better including RSA have been hacked um it's very hard for middle-sized companies or any kind of Enterprise that doesn't specialize in the topic uh to do adequate job um this I went to a my local business school had a uh conference on

computer security and this is one of the slides that was up there a couple of quotes um the favorite being uh there are only two types of companies left in the United States those that have been hacked and those that don't know they've been hacked um the the other line at the bottom there the best way to protect data is to get rid of all humans Plan B is to train them you know Plan B isn't working either and you know I think we need to go to plan C and plan C is can we find a better way to protect passwords that are being stored okay the existing methods are inadequate uh the obviously the the

worst case is just to store the raw password there are still some people doing that unfortunately we find out simple hash ing there are problems with that because you can build rainbow tables and whatnot salted hashing computational intensive hashing all all these things are increasingly vulnerable because um um as you'll see at the next Slide the computing power available to the attackers is just getting larger and larger so um people have come up with the idea of memory intensive hashes uh that has that pushes the the U the threshold a little higher for the attackers um but it's still expensive for large users of multi-user systems they can't tie up um uh a server for several seconds for

every uh person who's trying to log in or at least they could they could but it's it's expensive um and we still have the problem that the weakest password can compromise the system so that if you're uh once once you're in then you have the whole um panoply of escalation attacks available to you so um uh you know and all these things they help but they don't really solve the problem key hashes was mentioned earlier today in the this presentation um it's a good solution and in some sense you'll see rock salt has a lot in common with that but it's still a single point of failure you know we don't know what uh how

exactly we store these the key for the hash it's it's a very small value we don't even know if it's been stolen or not stolen okay so there's an arms race going on here between the Protectors of of of password validation uh data and the crackers and the crackers are winning and there are a bunch of reasons for that one of which of course is our favorite Moors law that's another thing I guess Moors law and and passwords have a lot in common their death is always being predicted um but they never seem to quite die uh but another big driver that is gaming computer gaming is a major driver of the industry and has

focused a lot of uh development work on building very high performance Graphics processors and the modern Graphics processors it turns out are just more than adequate for uh calculating um the standard hash functions which means that they are very good at uh um attacking large numbers of uh doing large numbers of password guesses at the same time so even though the the hash is salt Ed the the the the uh gpus can handle that um memory intensive hashes help but again gpus are getting bigger uh just a matter of time before they get big enough and then finally um you've got the whole issue of botn Nets which means that criminal elements have access to hundreds of

thousands of computers that they can put to work on attacking pass password hashes if they get hold of them and the cracking problem is of course massively paralleled you can't think of a better solution for a better problem uh to attack with parallel Computing so this is the problem I'm trying to solve okay and then you know the question is are really at this point um there was a couple earlier presentations on uh the keynote speaker from uh from uh FTC and and uh another presentation ear earlier in this room from n talking about increasing uh how to how to train people how to get people to be more um diligent and picking good password what is a good password you

know there's a whole lot of of uh um churning about this um there was a recent story that um Mark Zuckerberg of of of Facebook Fame his Twitter password turned out was was hacked and it turned out the password was ba ba ba you know and if somebody at that level who's very bright guy uh you know can be that sloppy in password picking you know maybe you know we're uh trying to climb a hill that's a little bit too steep um you also have the problem that passwords people reuse passwords so damage from one attack can can weaken other systems and you know at some point the the industry the problem is industry is

trying to store this data it really shouldn't be uh the responsible of users to fix this problem at some point you know there there has to be some way to solve this that is not dependent on users being ever more diligent and memorizing ever more longer passwords and even using diceware okay and Enterprise databases present an extra set of security challenges because they're in heavy use and that means there are multiple applications from multiple computers some of them accessing remotely um you can encrypting databases I mean there's there's this whole um technology being developed called homographic encryption uh yeah right I got that right anyway um where where you you can actually manipulate the data

while it's still encrypted but that's very um Cutting Edge research and it's not clear will ever be really practical enough for U day-to-day use but in general the problem with uh encrypting a database is that you know the encryption key has to be in the computer to access the datab datase and at some point this this becomes sort of meaningless also um password databases have to be backed up they have to be synchronized all this adds more attack surface and more more potential vulnerability and the volume of password information is fairly small I did a quick back of envelope calculation for 200 million username 200 million users the name the username plus hash Plus Salt less than 10 gigabytes and these

days you know 10 gigabytes you know isn't really is too inadequate for my watch you know I mean it fits in your pocket and and if you take the thing apart you can probably you know swallow it and it's just a very small amount of data physically um and then finally the attacker doesn't need the entire file attacker gets a you know can get a few hundred kilobytes of the of the password or even a few K of the password you know they have something to attack okay there are a bunch of alternatives to factor and buir metric they're cumbersome adoption has been slow um the typical user has lots of accounts so that right now you know you

can get a dongle for your bank or a dongle for your for your your company thing but how many dongles you going to carry around and as far as I know there are no good standards yet for interoperable dongles and that will present that will no doubt present another whole level of attack um there was an earlier report and I guess it was discussed also in this morning's uh discussion uh nist is I love having normally I try to avoid having too many uh acronyms but it's fun to put a bunch of them into one one one uh bullet point but n is depreciating using uh SMS text messages for out of band two Factor authentication because

as they as it was pointed out this morning it's too there are too many people like every every Clerk and every uh um cell phone um kiosk has the ability to generate a an SMS card with with a phony uh with a phony telephone number so that uh the the uh the uh validation message that came by through your phone could actually be diverted to somebody else's phone so there's so many insecurities that with that that that is which was actually one of the things that actually starting to work people are getting used to using your phones their phones as a authenticator it looks like that's that's like too dangerous and I'd also point out that

one without secure password storage then two Factor if you know if you it's if you have a leg that's on or or something that's standing on two legs and you cut down one leg you only have you only have one leg without without uh secure fast storage two Factor becomes one factor okay so that brings us to what is rock salt and it's somewhat similar to salted hashing or key hashing but it uses something uh that is sort of my invention which I call very large key cryptography um and very large and I use very large cryp key cryptography to transform the salt and doing so I make something that's hard to steal and makes

physical security feasible so let's talk about what this VK concept means and the idea here is to have a key that is actually much larger than the expected volume of data that's going to be encrypted now at at first that seems like crazy right I mean if you I have this little equation that Cipher keys are much smaller than onetime pads which in turn are much smaller than very large Keys you know it seems paradoxal One Time Pad is enough once you have enough uh key bites to encrypt every single character separately what's the point going beyond that and the answer is there are there are in fact some advantages to it um one of which is you

can get provable security and I can get that I think is going to be beyond the point of beyond the scope of this talk but it's pretty easy to see why but the most important thing for this talk is that a you get a macroscopic key a macroscopic sec secret a secret that is actually physically big okay and that means it can be physically defended and short leaks of that key if if if you use it properly are inconsequential okay um the very large it would be random or possibly pseudo random that's a whole other discussion um it can be many terabytes multiple solid state dis modules um and you compare this of ordinary Keys which can literally fit on

t-shirts um and and have in the past that's the that's a complete program for decrypting DVDs um and and of course the whole side Channel problem where where you're talking about a few hundred a few dozen bytes it's very easy to um not easy but it's it's very feasible to monitor power usage or monitor uh radio frequency aminations or a whole bunch of different ways of getting keys that are being used over and over and over again um the one example that I'm aware of for that's somewhat parallel to very large key cryptography is is deniable cryptographic file systems where you basically fill a dis with random stuff and then when you write uh um data into that dis you do it in an

encrypted way and hopefully if the encryption system is indistinguishable from Pure random data nobody looking at the disc and tell what's what's data and what's what's nonsense so that and and the point there being that you could then reveal part of what's there without revealing all of it but so far that's the only um precedent for what I'm talking about that I know about okay so let's go into a little bit more of the details and it's not complicated at all really once you once you get past this point normal password verification using salt uh you you look up the salt and the look up the the using the username as a key you you

look up their stored hash and salt in a database you hash the password that was submitted with that salt does that match the sto the stored hash if yes you're in if not you're not in okay everybody's familiar with this I hope at this point okay rock salt is not that different again you look up the stored hash and Sal in the database and I let me just go back a second here um obviously there's another step here when you which which I I'm not illustrating here but it's it's straightforward which is when you first set up the account of course you take the password you hash it and you put with a you you generate a

random salt you hash the password with that random salt and and that's what gets stored away in the in the in the database okay um for rock salt the main difference is you still look up the stored hash and salt you send the salt to the rock salt server the rock salt server uses the salt as a seed for a deterministic random number generator preferably cryptographically strong that picks out some number of bytes you know enough for uh say 64 bits or whatever whatever there's an engineering trade-offs there but basically nothing much different from ordinary salt you assemble those bites return it to the um password server as the rock salt and the rock salt then the server U does a hash

of that trial password with the rock salt if it matches the stored hash great you allow access if not you don't um um it's not that different um here's a here's a kind of a block diagram of how that works um users again they're they're accessing the computer pmm is the password password uh this my the password uh uh management module which is prob typically a dedicated server or servers in a in a Enterprise environment um that Comm that in turn communicates to this black box that I have down the bottom the rock salt server um it can either be via the whatever the corporate work is or even better with a optional direct link um

the password management module also talks to directly that little database symbol down there with the little file folders that's just the ordinary corporate database I'm not doing anything different to protect the corporate database obviously you want to protect it if you can but as I pointed out earlier that's hard to protect the only thing that's being protected here is this very large key that is literally stored in a safe and and the the left there you can see my little sketches of how that would work um the the solid state um memories would be put into little modules that might actually be keyed to make it hard to some interlocks would make make it hard to not

impossible just hard slow down anybody who got physical access from trying to copy what's in that and then the whole thing being locked in a uh in the safe and again once you have something that is physically large enough to protect there's a huge amount of Technology out there that's well established um you you you can obviously use a faraday cage to minimize any stray radiation you can attach alarm system to this one of the things about this is that the um rockol secret is static so that means it doesn't require any periodic maintenance the only reason to get in there is maybe a an electronic failure that you have to replace one of the modules so you can lock things in a

safe you can use I don't know if you're famili everybody's familiar with it but the whole concept of two person Integrity where you have two different you know it goes back to the um you know nuclear weapons launches where you have to have two people turning a key to launch a missile and uh certain government Seekers actually require two people of a combination um that kind of Technology can be used to ensure that no one Insider can can uh get at things and again with video surveillance by making this thing big enough the taking the time required to copy uh the key or or get meaningful amounts of data off the system is long enough that hopefully

somebody would would physically interrupt the process um you would presumably make more than one copy of this so so for an Enterprise you might have several of them operating at the same time and a few more of these modules um kept in a in a vault somewhere as backups um there there's tons of standards for uh both in terms of the electronic emissions from it and uh for the actual testing of safes um the un's laboratory has various standards the uh General Services Administration has their class five and class six standards there's all kinds of stuff out there that basically you know these kinds of really fancy safes cost a couple thousand dollars you know if you

think in terms of uh again an Enterprise service situation spending a lot of money to build a a box like this that that is secure uh we're talking maybe you know if we're selling this you know tens 20s of thousands dollars it's it's typical of Internet appliances and it's small compared to the uh what What's at risk by having um password data uh stolen another thing that can be used to protect us you since we do obviously you have that some electronic communication with this uh very large key is to use a Data Guard My Data Guard basically is is a microprocessor or even a um an A6 or fpga that's just designed to pass only

certain messages and at a rate limited level because uh the amount of data traffic required for the dayto DAT ongoing minute-by-minute password verification is much less than the data rate needed to exfiltrate uh sign enough of that very large key to cause damage uh um these data guards can be made they won't have they don't need an operating system they can be very simple easily audited software there's a lot of I think you you can now actually get uh stuff that will take has sculp code and and translate it into microprocessors you can so you can have stuff that can be be subject to proof system so that and you can actually have a series of

different uh um guards along the way one of one some of which just limit the data other of which um we'll talk about the second make certain um um statistical tests to see if the things come under other kinds of attack um the alternative the the major alternative that I'm aware of is is creating a separate database for uh password verification um somebody asked me a question on on the purist system I name is 1337 Mark uh is this are we talking about a secure Enclave for the for the passwords and uh the problem with that is it it complicates back of and synchronization of databases um large Enterprises may need to have more than one and more than one um

password database to uh allow you know multicon um operation of their of their business um all that synchronization places more creates more places where where uh data can be stolen and again a small link can compromise can cause compromises okay so again the big advantage of this is what we know from the user perspective is that you know we're back to passwords that are short enough that that really people are comfortable with them uh you still obviously have to limit or throttle fail login attempts so that uh a remote system doesn't sit there uh cracking away trying to log in over and over again but that's well established technology people do that and you know

it it doesn't require any new um any changes to existing practice the only thing you really have to a void is obvious passwords something that you can get from the Facebook account or uh you know any any some some social engineering uh pet names and stuff like that even the old you know a remember the I don't know how many people remember the old AOL this that used to be handed out but they'd come in a little card and there'd be like a little your password on it that was h two words of a with a special character in between that would be more than adequate for this kind of thing even ba ba ba would

be be fine okay so potential attacks um obvious one physical security violation again the use of alarm systems and monitoring systems uh again since this doesn't require anybody to access the system on on a normal basis one can be fairly strict in in terms of using um secure uh practices that are that are standard in Industry um one of the I think one of the major concerns would be malware that go somebody sitting inside the corporate system and using the rockol server to periodically you know check passwords and and uh um you know accumulate them and exfiltrate those out um I think the the answer to that one Bas there's a bunch of different answers there one of which

is to really have a secure link between the password server and the rockol server keeping track of how many requests and so on maybe even add some Canary passwords that would not normally be accessed um the the uh um the basic um thing to think about is that really if if the the software that's actually doing the password checking can be compromised the all the attacker has to do is get the passwords that as they're entered so you have to assume for for any kind of system that we have at least some Integrity in the actual password uh verification software itself again easy to guess passwords um I had put down using dictionaries to prevent um to prevent users from

selecting passwords that are too obvious uh actually there was an interesting comment made earlier that that actually may be counterproductive because when um when when I when somebody types in rle SK Rumple still skin as their password and it gets rejected they'll just type in rle SK Rumple still skin one and that actually creates a set of passwords that are uh you know um good ones to start trying but again um um there there may be some training required here or actually it maybe may be desirable not to look at a dictionary necessarily but look at uh things that you already know about the user so that for example they don't use their username or the

company's name or their personal name as as the as their password but this is again a much easier um a much easier challenge in terms of training people to just get them to not use things that really closely that some somebody can easily guess about them and of course any password system is vulnerable to that kind of attacks so summing up the advantages of rock salt it's Dependable it's engineered it can be proven from it security can be proven from first principles uh it eliminates the arms race because attackers don't get the opportunity to get to do offline password guessing even if they get hold of the database um it's even Quantum Computing resistant less burden on users

um the changes to existing password management practice are very small you one has to set up this communication link um and probably have some some field in the database that that tells you rock salt is enabled but that's about it um and and again the password data itself the verification data is just becomes part of the ordinary corporate database it can be backed up it can be handled no differently from any other user account information the transition is easy uh like we've we've thought about how to how to fall if people try this and they don't like it coming up with way to fall back uh to older systems if necessary I think there's a

confidence in confidence building step required here but the bottom line is a lot less risk and liability for the Enterprise and of course a lot less burden on users limitations um it's too cumbersome I think for small or personal operations again using key derivation functions uh it's probably the best bet for that it's not a solution as I said earlier for passwords that are used to drive a cryptographic key you can't use password hashes as a credential to share of other organizations other parts of the organization and that's not a good idea anyway business problems you know obviously this is a new idea getting people to try it will be interesting um there are a lot of questions there but

that's maybe for another discussion um finally I want to say that this is not necessarily the most elegant solution the idea of having building this you know terabytes and terabytes of information just to protect passwords seems CL clumsy but I believe it works and nothing else does and this if those of you who remember Raiders of the AR lost Arc U might remember this particular scene okay any questions uh I don't think there are any questions so we can just Matt starting this one okay so this sounds like it has a lot of uh similarities to Blind hashing by tap link which is they coin to turn security through obesity uh by essentially having a very large um hash

datab or or database that they would use in the hashing process it maybe I I haven't seen it I I should look at for it okay cool

thanks this is probably just my own brain fart because you definitely went into detail but why is it that um how is the RSS server able to verify all these passwords if the trusted module is stored separately and securely right all the all the RSS server does that this that's a good question all let me see if I can get back to the little picture um all the RSS server does is effectively create a way of transforming the hash that was stored in the database to a different sorry the salt that was stored in the database transferring the salt was stored in the database to a different salt and it does it in a way

that an outside attacker has no way of knowing what that salt value is so even though they get the salt that was in the database they can't use that to calculate the hash that's stored in the database so is it a salt token H how's that different from a salting token that represents the actual salt I I mean I'm not sure it is I'm not sure the difference here the difference here only is that by using a very large key you can defend this process that's that's the novelty a key hash would do this right but a key hash you have you have a 128bit or 256bit um key in that hash you have no

maybe you're using a Hardware security man module maybe somebody develops a new side Channel attack to that module there there you know it's it's a single point it's a very very fragile single point of failure the diff the the the the novelty here is using this very large key uh can you go back one frame or slide so uh is that accurate I think so maybe if I okay so there's a salt in the database then you take that salt give it to the rock salt server right it returns a salt for you it returns a different value yeah and then you hash that yeah so what's stopping someone from from getting into the server grabbing all the salts

requesting the rock salt server for all of those right and and I I I I mentioned that earlier and that that is that let me see if we get down to that the main the main thing is a to use a Data Guard that limits the rate at which you do this and then also maybe has statistical tests that say hm everybody's there seems to be a large number of you I believe you can get statistical patterns for what normal access is um and to distinguish between a systematic search but yes that and and then the other the other point is that um in this in this whole system I'm assuming that the the server that is

actually doing the password you know when you when you attempt to log in a password field gets sent to some server somewhere that server then then tells the rest system yep that's okay or no it's not okay right um if that server can be compromised you don't have to do anything more fancy than save all the passwords that get typed it so we have to assume that there's the ability to make that server um reliable TR that has to be trustworthy because if it isn't trustworthy like I say you just grab the passwords directly why bother with anything else so if you can make that if you can make that U reliable that becomes the only thing that has the

ability to talk to the rockol server it has a secure link so the rockol server is looking for looking for his sign messages from it whatever you know there's a variety of ways you can secure that link but the idea is to make that link secure so that it's not easy for somebody to infiltrate um software and and then do exactly what you're saying but that that of course is is the the the trick that has to be prevented so it sounds like your um your big win here is that you're protecting uh from the particular attack like offline attacks so somebody can't just get to the database and then do as many offline attacks with as many like

gpus as they possibly can right and you still have a bunch of the same problems that existing systems do but you've really locked down the offline attacks but if you if you were here earlier I mean it's the offline attack that's driving everybody crazy you know the the the the um I don't know if you heard the keynote but um the young woman who was speaking was talking about you know the fact that um um you know large numbers of people are are not with the uh requirements for people to change passwords they're using closely related password so once you get their password or one or two two examples of their password you can figure out their whole PR practice and

maybe try it out on other systems you know the whole thing becomes uh an arms race and the arms race is is not in the favor of people try trying to defend so it it sounds like the difference here between what you're doing I mean there there are obviously some mathematical differences uh between what you're doing and the and the idea of doing a key hbac on the hash uh but aside from that the it it sounds like the the fundamental difference here is that the secret that you're using is fundamentally larger than the secret that might necessarily be used used in in say an HSM uh for for doing an hmac is that is

that correct that's correct that's exactly that's exactly correct so basically your assertion here is that it's easier to protect a big key than it is to protect a smaller key yes and I guess I don't accept that that's necessarily the case I mean a lot of the things that you're talking about doing here in terms of protecting the rock salt server are things that you could do just as easily on an HSN to protect the hmac process right but how you know again how would you for example take take for example the question of side Channel attacks with an HSM um you could get uh if somebody came into the facility set up a monitoring

thing which you know the cleaning person or whatever um got the you know we're talking about 32 bytes of data here um you there's no way you you could have any confidence that that never happened um whereas with with this you have some it's an engineering thing you have some engineering ability to say uh you know I know what the amount of data is I know solid state drives actually can't be read out very quickly um you can actually make so you have a whole bunch of of again it's a defens and depth engineering solution that says I at least have the ability to get some conference I can review my um monitoring tapes I can do a whole bunch of things

to say that that data has not been stolen with some confidence whereas with an HSM maybe well I I we we'll just leave it and say that that I I think there are ways to protect against those side Channel attacks in hsms as well um the other the other part of this though is unless I missed it you didn't say anything about the size of the salt that that you were using here because in the in the other case we had a uh I think a perhaps a 32bit salt which is enough in order to essentially solve the D application problem here you're asking for an additional level of security from it that would require a much longer salt

I presume well I I I didn't talk about it and I I can um the short answer is there there are a couple things you want to do one of which is there there a couple engineering trade-offs you know it's assault at 64 bit or 128 bits is not a great expense in terms of databases and stuff like that um the and and then the Rockall sorry not even a question of database in terms of transmitting data back and forth and I there's there's actually a a bunch of trade-offs I I've considered here but um one of the reasons you want it a little bit bigger is there's always I mentioned that small amounts of data leaked from

the uh uh very large key don't do damage the reason they don't do damage is that probability would be you might get one or two or three bytes so you want to have the salt large enough so that one or two or three bytes um being compromised doesn't reduce its efficiency but it's not it's not a huge increase in size um and there's some actually other options here too one of which is um actually set a different mode which I talk about in my paper is uh sending the password to the Rocks salt server and have and and the and the hash letting and the salt and letting um the pass the uh rockol server

do all the calculation then just only send back a single bit which says yes or no so that that would even further reduce the amount of data that could leak out of the out of the server but the these These are engineering trade-offs but they're not they're not um in my opinion they're not that difficult or dramatic last one so you mentioned a uh deterministic random number generator on the previous slide is there any uh security concerns about that random number generator that would uh you would have to think about specifically with this problem where you have a very large key and you're trying to uh prevent exfiltration of even of a smaller key uh um the all the all the I

mean really any decent um deterministic Rand number generator will do the think about what's going on you're sending the salt which is becomes the key the seed for that deterministic Rand number Jer that is going to pick out 32 or 64 bytes out of the the entire um 100 terabyte 10 terabyte whatever memory and then those those th those uh that that string of bites will be the rock salt so the secrecy is simply the fact that the attacker has no idea what's in that very large key and in fact uh you can then begin to do spasic statistics given the volume of users and and what is the probability of that of any one bite being used even

twice and you can make that relatively small so that in reality the vast majority of bites that make up that key will never have been seen before so that that's really where the security comes from okay I think we'll stop it there uh Arnold will be around afterwards as well outside in the hallway uh so now we'll do our short break until 3:00 and next speaker up is Jeff Goldberg from jel bits makers of one password see you back then thank you than

[ feedback ]