[00:00.000 --> 00:01.640]  I get to cheat.
[00:11.310 --> 00:21.390]  All right. And we're live. All right. So we're here with Mike Stay,
[00:21.390 --> 00:28.990]  another fantastic speaker for virtual DEF CON safe mode. He is covering how he recovered
[00:30.250 --> 00:34.250]  a six digit sum of worth of Bitcoin from an encrypted zip file.
[00:35.130 --> 00:40.430]  And I guess if you just want to like quickly go into your talk, spend just like a minute or two,
[00:40.430 --> 00:48.750]  and then we'll start asking you some questions. Yeah, sure. So short summary is I used to work
[00:48.750 --> 00:56.230]  as a reverse engineer back in the late 90s. I broke the zip encryption that was used by
[00:56.230 --> 01:01.370]  InfoZip, which was the open source version. And so everybody accepts PKZip based their
[01:01.370 --> 01:07.990]  encryption on that, particularly WinZip that had like 95% of market at the time.
[01:08.470 --> 01:15.750]  And yeah, so then 20 years later, somebody locked up their Bitcoin in a zip file that they made on
[01:15.750 --> 01:22.790]  their Linux box and forgot the password. So they came to me and said, hey, I found your paper.
[01:22.990 --> 01:25.930]  What's the current state of the art? Can you help me with this?
[01:26.890 --> 01:29.670]  And this is your first time talking at DEF CON, right?
[01:29.670 --> 01:35.550]  Yes. Yep. So we've given him fair warning, but there is a tradition for first time speakers
[01:35.550 --> 01:41.850]  of DEF CON. They get to take a shot with us on stage. QA session is the closest thing to a stage.
[01:41.850 --> 01:47.290]  So thank you, Mike, for providing DEF CON with some wonderful content. Cheers to you, man.
[01:47.530 --> 01:49.350]  Thank you for having me.
[01:52.780 --> 01:54.220]  All right.
[01:58.040 --> 02:04.680]  Okay, so I was actually kind of surprised. So I have never thought about zip encryption as being
[02:05.540 --> 02:09.640]  something that would be difficult to get around. You did go into a couple of different types of
[02:09.640 --> 02:14.000]  encryption. I was also surprised that like, well, I wasn't surprised that early word
[02:14.840 --> 02:20.440]  was as difficult as it was. But later on, the 40-bit encryption that was just really difficult
[02:20.440 --> 02:24.640]  to brute force, that one kind of surprised me. Do you have any other... have you worked with
[02:24.640 --> 02:29.760]  any other type of encryptions that have been surprisingly difficult to get into for being
[02:29.760 --> 02:40.630]  such a legacy, weird proprietary protocol? Let's see. There were a couple where
[02:41.290 --> 02:51.750]  they clearly knew enough to be dangerous, but then completely screwed it up. Like early word
[02:51.750 --> 03:01.250]  perfect. You know, the founder of the company had broken that one himself. And then when they
[03:01.250 --> 03:05.390]  released their new version saying, oh, now we're using strong crypto, nobody will be able to break
[03:05.390 --> 03:11.570]  this. Went in and found that they took the password and then ran it through DES in the
[03:11.570 --> 03:17.550]  wrong way and got out some vector and then just XORed their file with it or something ridiculous
[03:17.550 --> 03:25.550]  like that. So they had DES, but they didn't use it right. It was so close. Yeah. There were ones like
[03:29.170 --> 03:37.050]  Microsoft Access 97, I think was one where they had RC4 encryption, but it was a fixed key. And
[03:37.050 --> 03:41.750]  so they would RC4 encrypt the file with this fixed key and then you'd go to this offset in the file
[03:41.750 --> 03:50.090]  and look up the password and it was just sitting there in plain text. Some of the details might
[03:50.090 --> 03:59.370]  be off. It's been 20 years. Fair. Go ahead. I want to ask a really, while we wait for people
[03:59.370 --> 04:02.510]  to come up with some really good technical questions to throw at you, I'm going to do
[04:02.510 --> 04:09.170]  one that... all right. So let's say that I don't know everything there is to know about encryption
[04:09.170 --> 04:15.170]  out there. Let's say I want you to do... I'm going to ask you to do a similar thing that you did in
[04:15.170 --> 04:22.350]  your talk. And I know that my password starts with a word and has some unknown thing after that.
[04:22.350 --> 04:27.950]  Are there things that I can provide you that I might know about the password that will help you
[04:27.950 --> 04:33.230]  get through this? Or does the encryption work in such a way that that doesn't mean...
[04:33.230 --> 04:39.970]  Dictionary attack, right? The product you're using has strong crypto. The guys that built it
[04:39.970 --> 04:43.910]  knew what they were doing. Then pretty much a dictionary attack is the only option you've got
[04:43.910 --> 04:53.910]  left. And so there are specialized attack software that you can get. One of them is called Hashcat.
[04:54.290 --> 05:00.590]  It's built for running on GPU farms. That was what we were originally looking at is maybe
[05:00.590 --> 05:06.470]  writing a Hashcat module for this. But it's really designed for processing a key space.
[05:07.490 --> 05:16.890]  And so you can give it a dictionary. You can then say, take this and then do all alphanumeric
[05:16.890 --> 05:23.170]  strings up to length six after it. Or take this and try all different capitalizations. Replace
[05:24.330 --> 05:29.970]  vowels with numbers. Say, you know, an I goes to a one or an O to a zero and so on.
[05:29.970 --> 05:35.150]  E to a three. Whenever you do that sort of thing, you can... there are these rule sets that you can
[05:35.150 --> 05:39.710]  say, okay, Hashcat, this is what you're going to start with and these are the rule sets that I want
[05:39.710 --> 05:45.830]  you to use when processing it. Because this is best in my memory what the password looked like.
[05:45.970 --> 05:50.490]  On the other hand, if you're doing something like correct battery horse staple from XKCD,
[05:50.490 --> 05:55.410]  you've got too much entropy. And that's really the way to protect your files if you're doing
[05:55.410 --> 06:03.130]  something is just make it longer, right? Because if you go from 26 characters, which is, you know,
[06:03.130 --> 06:16.130]  lowercase letters, to 97, you've roughly tripled. That's adding two bits per character to the
[06:16.130 --> 06:23.790]  entropy, right? So if you've got a length eight password, 26 to the eighth has, you know, all
[06:23.790 --> 06:30.370]  possible lowercase letters there. But if you go up to 97, all printable characters, that's only
[06:30.370 --> 06:37.630]  adding two bits per password. I'm sorry, two bits per character. So on a length eight password,
[06:37.630 --> 06:45.990]  that's, let's see, 26 is about five bits. That's 32. And two times eight is 16. So it's adding
[06:45.990 --> 06:51.690]  three characters to the length of your password. Adding printable characters to a password
[06:52.450 --> 06:58.910]  of the same length, you know, it's just adding a few more. But if you go and add a whole bunch
[06:58.910 --> 07:04.250]  more characters to your password, make it a long one, that'll make it really secure.
[07:04.750 --> 07:10.630]  Use a passphrase instead of a short random string. Yeah, and so if you, even if you're using
[07:10.630 --> 07:16.390]  English words, right, if you make it a passphrase rather than password, that'll make it really
[07:18.770 --> 07:24.990]  so vulnerable to a dictionary attack. There may be other attacks if the crypto is bad, but if the
[07:24.990 --> 07:31.410]  it'll protect you. So just this is entirely for my own curiosity. So after you broke through this
[07:31.410 --> 07:37.330]  zip file, you got the password that you could use to decrypt the zip file? No, we didn't recover
[07:37.330 --> 07:41.950]  the password. Oh, you didn't recover the password. Okay. Yeah. So the way the way zip works is it
[07:41.950 --> 07:48.290]  derives a 96 bit key from the password. And it was 96 bit key that we recovered. Now, if we wanted
[07:48.290 --> 07:54.030]  the password, we could take those 96 bits and then go launch a hashcat attack using dictionary and
[07:54.030 --> 08:00.010]  and some other stuff that that others have have worked out to get a few of the initial characters.
[08:00.290 --> 08:05.130]  That's where it fits into the type of password cracking that many of us are familiar with.
[08:05.130 --> 08:09.970]  Hashcat or John the Ripper. Okay. So if you've got the 96 bits, then there's something you can do
[08:09.970 --> 08:15.830]  with the dictionary attack that'll see whether the initialization process gives you those bits or not.
[08:15.830 --> 08:19.730]  That's great. Yeah, what I was going to ask is if you got far enough to see if like a dictionary
[08:19.730 --> 08:24.610]  attack would actually work against the zip file in less time than you spending all this time to
[08:24.610 --> 08:34.570]  brute force it. But if you didn't... He suspected it was on the order of, you know, 20 something
[08:34.570 --> 08:40.890]  characters or more, so it took him quite a while to to brute force. Would this technique that you went
[08:40.890 --> 08:47.410]  through work for any encrypted zip file? Yeah, yeah. This will work on any zip file with...
[08:47.970 --> 08:54.710]  So my original attack back in the late 90s required five bytes, five files in the
[08:54.710 --> 08:59.990]  archive with the same password. This one we were able to get away with two because we also knew the
[09:02.570 --> 09:09.770]  the timestamp. So if you've got the timestamp and you've got two files, then this will work
[09:09.770 --> 09:15.030]  on any of them. So how does the number of files affect the craftability of the zip file?
[09:18.770 --> 09:25.910]  When... Suppose you don't have the timestamp. Okay. In InfoZip, it was meant to run on Unix
[09:25.910 --> 09:31.230]  machines as well as Windows machines. So on PKZip, they just allocated some memory and used whatever
[09:31.230 --> 09:38.290]  bytes were there. Those random bytes. In InfoZip on many Unix machines, it would initialize the
[09:38.290 --> 09:43.970]  bytes to zero. And so there would be no randomness there. So they used the process ID and the
[09:43.970 --> 09:50.330]  timestamp to get a little bit of entropy and then fed the XOR of those two into C's RAND function
[09:50.330 --> 09:57.730]  and generated a bunch of bytes. But they thought maybe that's too weak, right? There were some
[09:57.730 --> 10:05.210]  known plain text attacks. And they're like, well, if they brute force the timestamp and the process
[10:05.210 --> 10:11.390]  ID, then they can derive the rest of these bytes. And so they took the password and encrypted those
[10:11.390 --> 10:16.590]  bytes once. And that's what they used as the random bytes when they encrypted that and the
[10:16.590 --> 10:22.870]  rest of the file. But when they encrypted it twice, because of the way the ZipCypher works,
[10:22.870 --> 10:27.950]  it produced the same stream byte twice at the beginning. So it encrypted it once and then it
[10:27.950 --> 10:34.470]  decrypted it for the first byte of each file. So when you say that, is it files in the archive?
[10:34.470 --> 10:43.690]  I have every 10th output of that C's RAND function and 40 bits were enough to figure
[10:43.690 --> 10:48.690]  out the 31-bit internal state of C's RAND function. So once I knew the internal state
[10:48.690 --> 10:54.090]  of C's RAND function, I could generate those first 10 bytes of each file. And then I would
[10:54.090 --> 11:00.890]  do a bunch of bit guesses. And because of the way the Cypher was designed, not all 96 bits were used
[11:00.890 --> 11:08.790]  when producing each output byte of the stream. So I guess like 40-something bits up front.
[11:09.070 --> 11:13.870]  And then because I had five files there, and I knew what those bytes had to be, I could filter
[11:13.870 --> 11:20.270]  all of those bits. I could say, I've got to know which of these 40-bit guesses are correct before
[11:20.270 --> 11:25.850]  moving on to the next stage. Got it. And so by having five files, I could both derive the internal
[11:25.850 --> 11:32.710]  state of C's RAND function and filter my guesses and finish one stage before moving on to the next
[11:32.710 --> 11:38.830]  one. And so it was a parallel divide-and-conquer attack. In this case, I only had two files.
[11:38.830 --> 11:44.070]  So even though I was making a 40-something-bit guess, I only had two bytes to filter it with.
[11:44.070 --> 11:50.250]  So I, you know, that meant 2 to the 24th wrong key guesses went to the next stage,
[11:50.250 --> 11:54.370]  and I had to guess more. And so it just kept getting bigger and bigger and bigger up to 2
[11:54.370 --> 11:59.330]  to the 60-something before I could start paring it down at the other end.
[11:59.330 --> 12:03.670]  So just for clarification, it's resetting the stream cipher every single time it encrypts a
[12:03.670 --> 12:06.030]  separate file, and that's why you're able to do this?
[12:06.030 --> 12:10.550]  Yes, yeah. So it starts over again with the same password, resets it to the original state,
[12:10.910 --> 12:15.550]  and starts from there. Because you want to be able to extract a single file from the zip file
[12:15.550 --> 12:17.370]  without having to extract all of them.
[12:17.370 --> 12:17.650]  That makes sense.
[12:17.650 --> 12:20.510]  I think you just answered one of the questions we got with the new attack,
[12:20.510 --> 12:23.590]  is there an acceleration in having more files in the archive?
[12:23.590 --> 12:29.050]  Absolutely. I mean, in the original attack, the more files you had, the faster it went.
[12:29.990 --> 12:33.450]  And so this is just a refinement of the original attack.
[12:34.650 --> 12:38.130]  But certainly having more files means more bits to filter with,
[12:38.130 --> 12:40.670]  and getting rid of false positives earlier.
[12:40.910 --> 12:44.150]  And sort of closely associated with that,
[12:44.150 --> 12:50.090]  do you know if this kind of attack works with the other encrypted archives like 7-zip and RAR?
[12:50.090 --> 12:56.070]  Most archival software now uses AES, like RAR5 switched to AES-256.
[12:56.070 --> 12:59.450]  So this isn't going to work against anything except zip files.
[12:59.690 --> 13:02.330]  Going for best standards, I like to see that.
[13:02.490 --> 13:06.370]  Even WinZip switched to AES a while ago.
[13:06.370 --> 13:10.370]  Fair enough. We had another question.
[13:10.770 --> 13:15.090]  Do you know if your client was the legit owner of the Bitcoin?
[13:15.970 --> 13:23.690]  I can't be certain, but we looked him up online.
[13:23.710 --> 13:29.310]  We knew his real name, and we looked him up online and found that he had reason to be owning Bitcoin.
[13:29.870 --> 13:34.610]  It didn't seem too shady. It wasn't someone reaching out across the dark web from...
[13:35.470 --> 13:38.610]  It was part of his employment that he would be dealing with Bitcoin.
[13:38.610 --> 13:39.610]  Fair enough.
[13:43.250 --> 13:45.070]  No, that makes sense.
[13:45.070 --> 13:47.530]  So this is really interesting.
[13:48.510 --> 13:55.190]  Do you expect with putting this out here and providing this talk,
[13:55.190 --> 13:59.010]  do you expect to get more of these requests to crack more things?
[13:59.010 --> 14:06.190]  If you do get more of these requests, do you have an answer pre-built of how you might respond?
[14:06.190 --> 14:17.130]  As far as breaking into Bitcoin wallets, yeah, when I first wrote this up on my blog,
[14:17.130 --> 14:19.090]  we got a whole bunch of requests.
[14:19.470 --> 14:25.090]  And for most of them, I had to say, nope, sorry, the best you can do is a dictionary attack.
[14:25.090 --> 14:29.330]  Many of them said, you know, I bought Bitcoin with a credit card ages ago,
[14:29.330 --> 14:30.730]  but now I can't find my wallet.
[14:30.730 --> 14:33.470]  Can you help me? I've got my credit card records.
[14:33.830 --> 14:35.570]  No, we need a little more than that.
[14:36.250 --> 14:44.130]  The one that was most interesting was a guy who claimed that his hard drive had crashed,
[14:44.130 --> 14:46.210]  that had Bitcoin on it.
[14:46.210 --> 14:48.650]  And so we were working with him to get some data recovery.
[14:48.650 --> 14:54.490]  But after a while, it became clear that he was perhaps schizophrenic or delusional,
[14:54.490 --> 15:00.090]  that he believed that someone was cheating him out of his Bitcoin and had stolen.
[15:00.090 --> 15:03.190]  Anyway, it was interesting.
[15:03.190 --> 15:10.670]  That said, there are about four situations where we could potentially recover software.
[15:10.670 --> 15:20.490]  One of them is if you printed out or wrote down the seed phrase for generating the 128-bit key,
[15:20.490 --> 15:20.710]  right?
[15:20.710 --> 15:25.550]  When you generate it, the wallet software always says, keep this in a secure place, right?
[15:25.550 --> 15:32.150]  And it's this 30-odd word phrase that'll generate the 128-bit key.
[15:32.150 --> 15:35.570]  If you've got that, you can recover the key, you can recover all your Bitcoin.
[15:36.210 --> 15:44.050]  The next case is if you have had damage to your hard drive, right?
[15:44.050 --> 15:49.190]  If the hard drive crashes, then the data in the sector is probably okay.
[15:49.270 --> 15:54.370]  And even if the data in the sector is bad, we only need eight bytes to be okay,
[15:54.370 --> 15:57.090]  that has the encrypted key in it, right?
[15:57.090 --> 16:01.030]  So if we can recover that data, then we can probably recover your wallet.
[16:01.790 --> 16:05.410]  If you have the wallet software, you don't have the original phrase,
[16:05.410 --> 16:12.290]  but you know you used a weak password, then we can try and do the dictionary attack approach.
[16:12.930 --> 16:20.830]  And then the least probable, there have been wallets with security flaws that make them
[16:20.830 --> 16:23.670]  susceptible to breaking more easily.
[16:23.670 --> 16:30.590]  And if you happened to use one of those back when they were being used,
[16:30.590 --> 16:32.530]  most of them have been fixed since then.
[16:32.530 --> 16:36.830]  But if you happen to use one that had a flaw, then we could try to exploit that flaw.
[16:36.830 --> 16:44.750]  Yeah, so this was an attack on a zip file, but you're talking directly about Bitcoin wallets.
[16:44.750 --> 16:52.230]  Do they also use some zip-like structure? Have you attacked the Bitcoin wallets themselves?
[16:52.890 --> 17:01.530]  The Bitcoin wallet takes the key, the private key information that you sign your transactions with,
[17:01.530 --> 17:06.610]  and a password, and generates a symmetric key from the password and some salt,
[17:06.610 --> 17:08.650]  and then encrypts the private key.
[17:08.830 --> 17:12.050]  So that private key is really what gets you access to the Bitcoin.
[17:12.050 --> 17:17.990]  What we can do is try to either recover the private key by means of that really long phrase,
[17:17.990 --> 17:20.270]  regenerate that same private key.
[17:20.890 --> 17:24.330]  Or we can attack the password, if you've got the wallet,
[17:24.330 --> 17:27.090]  so that we can decrypt the private key that you had stored.
[17:27.090 --> 17:33.490]  Or we can attack some flaw in the cipher where, for instance,
[17:35.170 --> 17:40.370]  when they were coming up with the symmetric key, they didn't use the entropy properly.
[17:40.370 --> 17:43.590]  And so there's a much smaller key space that we would have to brute force.
[17:43.750 --> 17:47.970]  There are very few of those that were out there, but there were some.
[17:48.550 --> 17:50.930]  There's a possibility we could do that.
[17:52.450 --> 17:57.890]  So I like asking this question to people who know this technology really well.
[17:57.890 --> 18:01.450]  Feel free to tell me, no, you're not going to answer this question,
[18:01.450 --> 18:06.410]  but do you yourself hold any value in any cryptocurrencies?
[18:06.410 --> 18:08.790]  Because you seem to understand how it works.
[18:09.430 --> 18:17.750]  Um, I don't, because I have... I mean, there's no inherent...
[18:22.400 --> 18:25.160]  When you pay taxes, you pay taxes in dollars,
[18:25.160 --> 18:28.260]  because the government says you have to pay taxes in dollars.
[18:28.260 --> 18:33.520]  So there is this built-in necessity to own dollars at some point.
[18:33.520 --> 18:39.320]  There is no built-in necessity to own Bitcoin or any other cryptocurrency, right?
[18:39.320 --> 18:48.680]  There's... and for Bitcoin and Ethereum, I think that proof of work has shown itself
[18:49.260 --> 18:57.020]  to be susceptible to attacks like Sybil attacks, 51% attacks,
[18:57.020 --> 19:03.940]  like Bitcoin Cash and Ethereum Classic have both suffered 51% attacks.
[19:03.940 --> 19:06.680]  They were, you know, rebuffed eventually,
[19:06.680 --> 19:10.200]  but, you know, if Google wanted to deploy their whole infrastructure,
[19:10.200 --> 19:12.720]  they could completely own Bitcoin.
[19:12.760 --> 19:19.480]  There are existing companies that could do that, not to mention nation states, right?
[19:19.480 --> 19:23.400]  If the US wanted to take it down, they've got this thing in Tooele here in Utah
[19:23.400 --> 19:29.080]  that they could deploy against taking down Bitcoin.
[19:29.080 --> 19:36.060]  So my personal take, and we designed a system to do this,
[19:36.060 --> 19:39.380]  is that you need to use a consensus algorithm with true finality,
[19:40.520 --> 19:43.280]  that proof of stake and bandwidth.
[19:43.780 --> 19:46.880]  And then after a certain point, when you have enough witnesses,
[19:46.880 --> 19:49.740]  you say, this block is finalized and it can't ever change.
[19:50.280 --> 19:55.660]  Ethereum is trying to move in that direction with their proof of stake algorithms, but...
[19:56.680 --> 20:02.220]  Yeah, I've heard of proof of stake, but the finality piece is new to me.
[20:02.880 --> 20:04.960]  You've definitely given me a few pieces already
[20:04.960 --> 20:06.860]  that I'm going to need to go Google.
[20:07.320 --> 20:12.920]  So we got another question. It's sort of a meta question.
[20:14.960 --> 20:19.400]  One of the people that watched your talk had a little bit of struggle following your math.
[20:19.400 --> 20:23.020]  They understood all the aspects individually that you talked about,
[20:23.020 --> 20:27.800]  but zooming back out, they seem to lose pieces in their head.
[20:27.800 --> 20:32.000]  And they want to know, how do you juggle this?
[20:32.000 --> 20:35.920]  Are you aware that some people that follow your talk might have difficulty
[20:36.640 --> 20:38.880]  zooming in and out like that?
[20:39.080 --> 20:46.380]  Yeah. So I had some options when doing this talk.
[20:46.380 --> 20:50.780]  One was to go really deep and really hard on the technical stuff.
[20:50.780 --> 20:54.540]  Another one was to give enough background and the basic idea
[20:54.540 --> 20:58.860]  of how this attack played off and the challenges we faced.
[20:58.860 --> 21:07.320]  So I chose to be less detailed for the sake of the story rather than go deep into it.
[21:07.600 --> 21:11.400]  If anyone has any technical questions, take them offline.
[21:11.400 --> 21:15.720]  I'll be happy to talk through them with you and point at lines of code and that sort of thing.
[21:15.720 --> 21:17.140]  That's great. That's awesome.
[21:17.420 --> 21:25.240]  As far as keeping it in my head, I would have to wake up and then come down and reload everything.
[21:25.240 --> 21:28.540]  I had stuff on whiteboards all over my office, pictures.
[21:28.540 --> 21:32.680]  It was a process. I would even have to remind myself about what was going on
[21:32.680 --> 21:35.640]  because I couldn't keep it all going at once.
[21:35.640 --> 21:40.800]  And it was a months-long process of trying to think through over and over again
[21:41.320 --> 21:45.900]  how things are going wrong and what I might be able to do to fix it.
[21:45.900 --> 21:52.340]  So if you don't get it from one short 45-minute talk, I certainly don't blame you.
[21:52.640 --> 21:53.980]  Makes sense.
[21:56.620 --> 22:00.520]  Did we discuss this at the end? I'm sorry, I missed this point.
[22:00.540 --> 22:03.660]  Did you actually get any compensation for this work?
[22:03.960 --> 22:08.880]  We did, yeah. So when he first talked to us, we said we'd like so much up front.
[22:09.180 --> 22:12.120]  We estimate that the total cost will be about this much.
[22:12.680 --> 22:15.460]  We took longer than we said we would.
[22:15.600 --> 22:19.240]  We expected it to be done in three months.
[22:19.360 --> 22:22.340]  That was October, so November, December, January.
[22:22.340 --> 22:28.220]  It was April before we actually, late March, before we actually got the key back.
[22:28.240 --> 22:32.580]  But because of all of the extra cryptanalytic work that I did,
[22:32.580 --> 22:35.920]  it took a tenth of the time on the hardware.
[22:35.920 --> 22:41.180]  So the hardware cost ended up being only roughly 10, 15 grand
[22:41.840 --> 22:45.060]  as opposed to the 100 grand that we thought it would take at the beginning.
[22:45.060 --> 22:47.840]  So we gave us a bonus afterwards, which was nice.
[22:47.840 --> 22:50.400]  I actually missed this.
[22:51.180 --> 22:55.880]  Another one of the speaker goons mentioned that it was on AWS.
[22:57.220 --> 23:03.740]  And they want to know if the 10 to 15 was about what you were expecting from compute cost.
[23:04.240 --> 23:07.180]  No, we were expecting it to take far more.
[23:07.180 --> 23:11.540]  The original estimate was around 2 to the 64th work,
[23:11.540 --> 23:16.540]  which is comparable to finding a collision in SHA-1,
[23:16.540 --> 23:18.460]  which is 100...
[23:20.240 --> 23:25.740]  Sorry, SHA-1 was 160. MD5 was a 64-bit thing.
[23:26.140 --> 23:32.520]  And there were some recent work where to find a collision,
[23:32.520 --> 23:37.500]  they had to deploy an enormous amount of work to do it.
[23:37.500 --> 23:43.460]  I guess MD5, they were able to do because of flaws in the hash function.
[23:44.200 --> 23:51.280]  SHA-1 took roughly 100k of GPU time to break.
[23:51.280 --> 23:55.760]  And so we were estimating it would be comparable to do this.
[23:55.760 --> 24:00.280]  And this is what your company does, like data recovery?
[24:00.280 --> 24:01.660]  Or is it specific to...
[24:01.660 --> 24:03.120]  Not originally.
[24:03.120 --> 24:08.660]  Originally, we were working on a distributed operating system.
[24:09.980 --> 24:13.880]  And we could get clients interested if we can get in the door,
[24:13.880 --> 24:16.620]  but it was right at the time when cryptocurrency was taking off,
[24:16.620 --> 24:19.240]  and we didn't have to talk to anybody to get them in.
[24:19.900 --> 24:22.780]  We started doing some consulting work there,
[24:22.780 --> 24:28.980]  built up a team of about 20 scholarly developers that were top of the...
[24:30.840 --> 24:33.300]  cream of the crop, top of their field.
[24:33.940 --> 24:39.780]  And then built the rChain cryptocurrency platform.
[24:40.220 --> 24:42.920]  rChain started having some financial troubles.
[24:42.920 --> 24:46.560]  We allowed them to hire the devs early.
[24:46.560 --> 24:49.000]  We had a contract that we'd hold on to them for a while,
[24:49.000 --> 24:52.180]  and then they could hire them after they'd worked for us for a year.
[24:52.180 --> 24:54.020]  But we let them hire them early.
[24:54.160 --> 24:56.820]  So they've taken over the dev team.
[24:56.860 --> 24:59.180]  And then we started working on some other things.
[24:59.180 --> 25:03.280]  And this particular consulting job came up at a nice time.
[25:03.280 --> 25:04.540]  It was a whole lot of fun.
[25:04.540 --> 25:10.240]  But right now we're looking for any interesting consulting work that people have.
[25:10.240 --> 25:14.900]  That was exactly what I wanted to segue into now that you've done this talk.
[25:15.300 --> 25:21.460]  Do you have another research item on your to-do list that you're trying to aim at?
[25:22.220 --> 25:23.100]  Sure.
[25:23.820 --> 25:30.260]  At the moment, I'm doing some consulting work for the Ethereum Foundation.
[25:30.260 --> 25:38.140]  I've got some consensus algorithm research that I'm working on.
[25:38.730 --> 25:44.140]  We got access to GPT-3, so we're building an adventure game,
[25:44.140 --> 25:48.920]  kind of like AI Dungeon, but with more structure using GPT-3.
[25:49.300 --> 25:53.800]  We've got various ideas for voice assistants
[25:53.800 --> 25:59.040]  that will be able to call somebody at a restaurant
[25:59.040 --> 26:02.240]  rather than figure out every different restaurant's online ordering system.
[26:02.240 --> 26:06.920]  You just have your assistant call them up and have a conversation.
[26:07.140 --> 26:11.000]  GPT-3 seems to be able to have conversations, so maybe we can use that.
[26:11.100 --> 26:14.560]  This is probably a really small piece of what you're doing,
[26:14.560 --> 26:17.660]  but I used to be incredibly into MUDs.
[26:17.700 --> 26:22.160]  So an adventure game that's generated by GPT-3 sounds interesting.
[26:22.160 --> 26:28.460]  Yeah, so we're working on the room generation for quests.
[26:28.460 --> 26:32.100]  You have to convince this character to give it to you.
[26:32.100 --> 26:34.920]  He's got desires and needs.
[26:34.920 --> 26:38.760]  So you'll have to be role-playing while you're doing this game,
[26:38.760 --> 26:41.580]  interacting with these characters.
[26:41.580 --> 26:45.260]  There is a person that goes by the handle Evil Mog,
[26:45.260 --> 26:49.360]  is running a DEF CON CTF MUD right now.
[26:49.360 --> 26:52.180]  Just a shout out to him.
[26:52.300 --> 26:54.440]  We are really close to being out of time.
[26:54.440 --> 26:57.980]  There are a lot of questions over here about specific pieces,
[26:57.980 --> 26:59.400]  specific technologies.
[26:59.400 --> 27:05.540]  I think I'd like for people to bring those to you on a less moderated basis.
[27:05.540 --> 27:07.880]  So we'll let those go for now.
[27:08.060 --> 27:11.240]  Before I let you go, I want to know,
[27:11.240 --> 27:14.920]  what is the thing that you would like us to take away from this?
[27:14.920 --> 27:20.660]  If there is a final idea that we should walk away from your talk.
[27:25.260 --> 27:28.020]  That attacks on cryptography only get better.
[27:29.340 --> 27:37.200]  At the time MD5 was proposed, 128 bits for a 64-bit attack was inconceivable.
[27:37.200 --> 27:42.020]  And yet, within 5 to 10 years, they were able to attack that one.
[27:42.020 --> 27:44.700]  And then SHA, there are attacks.
[27:44.920 --> 27:50.100]  AES with the bi-click attack, they've now broken, I think,
[27:50.100 --> 27:52.840]  seven or eight of the 10 rounds.
[27:53.140 --> 27:56.180]  If there is something that you need to keep secure,
[27:56.180 --> 28:01.380]  choose the best software and have a plan for upgrading your crypto
[28:01.380 --> 28:03.540]  and any products that you put crypto into.
[28:03.660 --> 28:05.520]  Because the attacks are going to get better.
[28:05.520 --> 28:10.260]  You'll need at some point to transition from the broken system to a new one.
[28:10.980 --> 28:15.360]  And so that will come up during the lifetime of your product.
[28:15.360 --> 28:17.400]  So be thinking about it.
[28:17.680 --> 28:19.460]  That's definitely good advice.
[28:19.460 --> 28:19.740]  Yeah.
[28:23.880 --> 28:26.440]  Falvo, you got any more questions you want to sneak in under the hood?
[28:26.880 --> 28:28.120]  No, I think I'm good.
[28:28.120 --> 28:30.560]  I really appreciate the work that you've done here.
[28:30.560 --> 28:35.900]  And thank you for coming to present and giving your time to this Q&A session.
[28:36.420 --> 28:39.420]  There are some more people that have some more questions coming in,
[28:39.420 --> 28:40.880]  if you're willing to do so.
[28:40.880 --> 28:45.800]  If you would put your contact information in the TrackOne channel on Discord here,
[28:45.800 --> 28:47.980]  we will get that out there.
[28:47.980 --> 28:52.600]  Folks can look you up if you're willing to be available to that.
[28:52.600 --> 28:55.720]  I also recommend you put all of your company information,
[28:55.720 --> 28:56.920]  if you're willing to do so,
[28:56.920 --> 28:59.880]  because that's a good way for people to find you
[28:59.880 --> 29:02.060]  for those contracts you were talking about.
[29:02.440 --> 29:04.220]  Great. Thank you very much.
[29:04.220 --> 29:06.300]  All right. Take care.