*Music*
Herald: And give a great round of applause to Sebastian Eschweiler!
*Applause*
Sebastian: So hi everyone. So I want to talk about how I defeated not (Not)Petya's
cryptography. Some I'd say that (Not)Petya would be Ukraine's scourge, and for those
of you who don't know what the word scourge means: this guy right here doesn't
know either. And quick trivia quiz - does anyone know what this movie is? What's the
name of the movie? So, in the next scene Johnny Depp enters. Does ring a bell? Jim,
a movie by Jim Jarmusch. Soundtrack by Neil Young? Dead Man, right! Great! It's a
great movie. So if you want to know what a scourge is then you could watch the movie.
So let's begin with my with my talk. So this is what actually the official Ukraine
Twitter account tweeted some time ago in at the end of June 2017. And there was an
outbreak of a ransomware attack which was noticed mostly in Ukraine but also all
over the world. So millions of users and also companies large companies were
affected, and the damage went into the billions of dollars. So, the problem there
is, I mean, this is this is not the everyday ransomware outbreak you have
there. And I want to give you a short glimpse into the the (Not)Petya universe.
And also how I could decrypt all these stuff that, yeah, actually was encrypted
by the this ransomware outbreak. So first I want to begin my talk with a
differentiation. I want to draw a demarcation line because all this
(Not)Petya universe - there's much sub- summarised under under this whole label.
And I really, I'm just talking about a small fraction of this whole universe. So
I will first distinguish between what my talk will be in what my talk will not be
about. Next I will describe (Not)Petya's cryptography, and especially (Not)Petya's
cryptographic failures. Which I then will be exploiting in the remainder of the talk
and see how can the users get their, yeah, vacation photos back. So what was this
whole thing? The outbreak started, as I said, in June 2017, and it started as fake
update or as malicious update from a software called Madoc
- this is a tax software, one of the two official tax softwares in the Ukraine. So
almost every company has it installed on tax accounts on their computers many
private persons have it installed. It was pushed and then site loaded this file
perfc that was then downloaded to the computers and it comprises several parts.
And some parts are more interesting than then as others, so one component ever like
half an hour time it would start encrypting the files depending on the
access level. So, if there wasn't any access to infect the computer with well
this MBR infector. then it would just based on the current user level encrypt
the files based on that current user. In lack of a better name I would call this
"Mischa" component I know it's usually somewhat different, something different.
However, this was the best name I could find there. So it's basically just a
finite crypter with AES. My talk will not go about this this part - this file
infector. The next very interesting component was the spreader part - it's
basically based on the EternalBlue/EternalRomance exploits that
had been leaked by the Shadow Brokers. My talk will not go about this as well. This
is a whole different universe as well. What my talk will be about is the actual
(Not)Petya component and this is an MBR encrypter and I will show you in the next
slide what it's actually about. So, the user will see something like this upon
reboot. So if the access rights are granted so if there is some local admin
installed on the computer or the correct password could be guessed by some attack
and then this dropper, the perfc that would infect the system by overwriting the
Master Boot Record with a custom boot loader. And it would reboot the system
after a predefined time - usually being about 10 minutes. And then the the actual
(Not)Petya compound would kick into action. This infected MBR, the bootloader
shows this decoy CheckDisk screen, and in the background would find and iterate the
old files on the file system and
encrypt all these files. So the main takeaways of this slide are
that we are dealing with 16-bit code here. So we're we're in 16-bit real mode - so
this means no proper file system it means no 32-bit or 64-bit code. There are no
windows APIs-- so debugging all this and analyzing this is a tedious work. However,
we have something on the plus side which is a BIOS, you know, the basic
input/output system and with that comes a range of interrupts that are very well
described and a really nice thing is having Bochs and being able to debug all
this in in IDA. So this was a really neat plugin that had been developed by the
authors. So let's analyze a bit and check the cryptography and why implementing
crypto is really hard. So I will start this part with describing in short words
the theory of Salsa20 and then check that compare that against the (Not)Petya
implementation of this cipher. So Salsa20 is a stream cipher. So basically you will
have a plaintext, it's it's about here and then you will have some kind of random
number generator or pseudo-random number generator and then apply some operations
on the plaintext and out comes the ciphertext. And what you put in there are
four different variables, or four different inputs, because there's the
constant part which is obviously not variable. But we'll see about that in a
bit. So you have these key and the nonce, and then there's this really nifty thing
called counter. What's so nifty about that is if you were choose to stream a Salsa 20
encrypted stream and you would lose some frames then you could adjust this counter
variable which would de-mark the offset of the current stream in the current stream
and then could continue needlessly with with the decryption of the stream. So this
is a very nice feature. The size of the counter is 64-bits and the hash size here,
so what salsa does is create a 64-byte hash for every different of these inputs
and with that then apply to the input. If you want any more details about this salsa
cipher, the inventor of salsa should be in this room, and should be in at the
convention. He is at the convention: I just rode the train with him, so I guess
you can ask him the the gory details of salsa 20. So it's a really nice crypto
cipher and you should hit him up and ask him. I shouldn't have said that, right?
Sorry. So basically what a very important thing is to note is for every invocation
of this this or for every instance of this (Not)Petya encryption and you would have
these three variables or these three inputs be constant so (Not)Petya would
would patch during the infection process the key, the nonce, and the constants into
a configuration sector. The constants, not these are somewhat different. And then the
counter would only change throughout every iteration. So the interesting thing or the
interesting question was first - what is the length of the key stream? So, the key
stream, you know the the number of different outputs that that would come out
of this hashing function. And I mean for this implementation for the theory this
is quite clear it's 64-bits here eight bytes times the 64 bytes of output so it
would be about two to the seventy of a periodicity. One different about the
actual implementation in (Not)Petya on the theory would be that this constants thing
here had been changed to I string a reading out invalid sect ID. So this would
break the official implementation. So the very first failure I saw in (Not)Petya was
something like this. So I think I can slip this slide because it's obvious for
everyone that this is a fail right? So who sees the fail? So, not many hands? Okay,
then then I'll explain it. So I was just kidding , I'm almost not not expecting for
for you to grasp of that first. So remember, we're in 16-bit code. We have
here this shift left operation which would shift a register by N-bytes. The register
with here is 16 bits, so it only has 16 digits so to speak and you would shift it
by 16 - by 10 hex - sixteen. And this would effectively null the register, and
even worse is here. So
you would shift a an 8-bit register for sixteen. So this is something you you
wouldn't expect from my proper cryptographic implementation. And I was
was really intrigued why that is, because it wouldn't make any sense in source code
and and did the (Not)Petya or the Petya authors really implement that on purpose,
or what was the gist with it. And I looked up the (Not)Petya, the salsa 20
implementation um I just googled it and funny a nice website that had a
implementation of salsa 20. And there you would see this code. So you see here it
sits in the the endianness conversion. And you see here these these shifting of bits
of registers and you see here this this uint fast 16 or 32 type. So it becomes
quite clear that this is a broken implementation right? So everyone can see
that right? No, not right now because you need to know some things more about this.
There are two important facts that make this implementation broken and the two
facts are: you need to compile this code for 16 bits, and you need to look up what
Visual Studio makes of these these type definitions here. And when you look that
up, this is from Visual Studio and it's in the standard int.h header file. And there
you see it's interpreted or translated as unsigned int, so this is the base type.
And this base type, unsigned int, in 16-bit code is a 16-bit variable or a
16-bit register. And then everything makes sense. And this was somewhat of a a
failure here - the authors didn't really check if their code was actually working
against the test vectors. And this guy who wrote the code here on this salsa 20
implementation made this mistake also. On this slide you see two bugs off of the
(Not)Petya implementation of salsa 20. And I quickly want to to explain both to you
because they are of some somewhat in importance throughout the remainder of the
talk. So, both revolve around the the counter variable. Just remember - this
counter variable is the only dynamic input the only variable input throughout all
these salsa 20 invocations.
And the the first error is: so you read a sector, a sector number into the memory.
So a bit about the the low-level aspects of a hard drive. A hard drive from the
view of the BIOS would look somewhat like a bunch of different sectors. So these are
512 byte chunks of data, and they they come one after another. So if you were to
read a sector, you would actually read a 512 bytes about me a byte long portion of
data. And this is obviously not the offset in the stream, and this is somewhat of a
problem there. So, you see here the same variable is used to decrypt or encrypt the
data. And, I mean, this this is it doesn't it isn't really apparent to to the
implementer of this cipher. However, if you were to analyze it, it would look
something like this. So you would have the key stream of two different sectors, two
different consecutive sectors here. So it would start with with FF and then
continues with D7 and so on. And the next sector would have almost all of the bytes
identical. And this is yeah a really big failure because this really nice salsa 20
implementation, this really nice salsa algorithm will then be, from would then be
converted from a one-time pad to a many times pad. And this is the first fine I
wanted to show you in this very few lines of code. The second part is, the second
bug is here this large keyword. Remember, we are in 16-bit code so this large
keyword here does not push a 64-bit variable as we would suspect to do it, but
a 32-bit variable. So only 32 bits of this this nice counter variable are actually
used in this case. So, these two failures are somewhat of a problem for this salsa
20 implementation. So, in this slide I took two different hex dumps, and these
hex times were are within this expand key function. And they they are well basically
two snapshots - one right before these bugs become apparent: so before this this
endianness conversion, and right after on the lower half. So you very nicely see the
different variables being put into all the different key inputs being put into these
this memory blocks. So here, it would
spell out invalid sect ID, you know, the constants (Not)Petya uses. Here you would
see the key and here, so it's broken into two halves. Additionally you would see the
nonce here. And what really sticks out is this bunch of zeros here. So this this
higher part of this a 64-bit variable isn't even used - is it's not even filled.
So this is well the first problem here, and after the endianness conversion you
see that it's not really an endianness conversion but it's more of a nulling of
of bytes. So the result would be that this initially 64 bit variable would be just
16-bit in length. And, as I said earlier, the original salsa implementation would be
2^70s key lengths. And right now we have 16 bits times 64 bytes in in key lengths
which would result an in 26 bits in key lengths. Which would be a measly 4
megabytes in key lengths. So this is the this was a very interesting observation I
made there and this would be possible then to decrypt together with the many times
pad properties of this cipher which make it really easy to break. So to quickly
summarize this part of the talk - so we have a very very short key stream of just
4 megabytes, it's highly repetitive repetitive. So for each secretary progress
you would only have a progress of one byte at a time. So only 26 bits remain of the
whole stream. And as I said, the many times pad property's a very nice thing to
to analyze. I could come around to implement a small joke here, so this salsa
implementation I would only call "LOLsa" from now on. Sorry, is a bad joke sorry!
So, the the main goal is to derive the keystream, and as I'm not really a crypto
expert, the basically the only attack I know it would be a known plaintext attack
so this was my goal there because it's so straightforward to do that. And in the
remainder of the talk I will tell you how I did that. So without further ado, let's
exploit these failures and see how much of the plaintext we can actually get from a
(Not)Petya infected drive. So the modulus operandi
of (Not)Petya would look somewhat like that. This, so let's let's
stop with the with the left hand side of the of this slide, and concentrate on the
right hand side. For those of you who you are not really intimately familiar with
NTFS - I wasn't before analyzing Petya or (Not)Petya as well so no worries. It's
quite simple - so every NTFS partition has something called an master file table.
MFT, abbreviated. And it would contain some metadata about the file. For example,
the file name, the file size, and if the file is small enough, it would even fit
the actual content of the file into this record. So, as I said, MFT is just list of
records. And if the file is larger it would have a pointer, a so called data
run, which would point to a cluster or sector on the disk on the partition which
would then actually be the the payload data. One of these MFT records is one
kilobyte in size. So now to the actual implementation. So let's zoom out a bit
and see how this LOLsa implementation is used in (Not)Petya. So it would basically
just iterate over over all of these MFT records, and then check if this record
would put into would point to a file. If that is the case, it would encrypt the
first kilobyte of the file, and then would encrypt the record itself. This
implementation is good for a bunch of reasons - it's very fast: You would only
need to encrypt the first kilobyte, and this is this first kilobyte contains
really really important information. For example, headers, or especially compressed
files have these really important header structures there. Additionally, your file
recovery tools wouldn't be able to work anymore because most of them rely on this
very header. And the second thing is this MFT is can be considered as table of
contents. So with no metadata, with with no pointers to these to the files, you
won't have anything there to work with to recover from. And this is a I mean from
from the implementation standpoint it's very neat, because it's fast and it's a
somewhat thorough. As the MFT is
really important, my idea was to to recover that first and then check what
what comes out from there and see how I can can further progress there with the
decryption of the files. So the metadata would would be of most importance there.
I'm a visual person, and here I took two disk dumps from a from one of my test
disks. So I infected a clean system with (Not)Petya and let it encrypt the hard
drive. And on the left-hand side you see the plaintext on and on the right-hand
side you see the encrypted data. So to just get a better picture about the
encryption process. On the far left-hand side fancy PowerPoint altered animation,
you see some kind of indicator so which which would tell you at which offset, how
much of the of the data has actually been different. And you see the whole disk is
more or less being encrypted. However, you see at the far bottom part here it's more
dark red. And this is actually the MFT, so the MFT is towards the end of the disk
sometimes. But this might be a misconception. So my my idea was something
like this: we have two input sizes, right? We have the the encrypted MFT, and we have
encrypted files. And first i would analyze the MFT, and then derive the key stream
from that. After that analysis stage had been finished I would put the key stream
back into the this this little box here, and actually decrypt that. And then out
comes the decrypted MFT. And with that and the key stream I would be able to find the
encrypted files on the disk, and then be able to decrypt them; then be ready with
it right? So this was my initial idea there and so let's start with the
decryption of the MFT. Known plaintext attack, right? So an MFT you looks for
from from the viewpoint of the keystream, somewhat like this. So you would have here
the first, the second and so on MFT records. And on the on the column you will
have the actual byte that is used as key to encrypt the key stream. Remember, the
operation that that encrypts the you know the the key stream and the the plaintext
is just a mirror XOR operation. So you have the the key
stream and the plaintext, and it's plainly - so you can switch forth and back between
plaintext and ciphertext and even the key stream with a with just applying an XOR
operation. So what you see here is for the very first records you only have very few
key stream bytes or very few sample bytes. However, as the progress as you make
progress with the analysis and then you will have more and more of these sample
bytes to collect from and this this will give you more confidence in the in the
result, and the may be known key stream then. The question is, does the MFT hold
enough plaintext to do some some kind of known plaintext attack? So let's look into
the specification. The MFT record has basically two fields. So there is this the
standard information, which is a well- defined structure and there's something
else called attribute list, which is a quite dynamic structure and this would be
a somewhat more different, difficult to clean plan text from. So I concentrate on
this first part. And the first part quickly turned out to be quite constant
for many or most of the MFT records. And you see it starts with FILE and then as
some some hex digits after that. And although on the far bottom part of the
slide, I added my yeah certainty level. So the the certainty level would be the
number of different sample bytes I would have multiplied by the confidence I would
have in that sample byte being actually this this plain text. So you see for the
very first record, we would have a quite low, of a low certainty. I mean, it's just
one byte, right? Oh, the two byte skipping is I mean quite a forward considering you
would have usually 512 bytes per sector on a disk, and the MFT record is one kilobyte
in size, so the stream would progress two bytes. And for record 100, so for if for
the 100th record I would have a certainty of four. You know, I would just assume
these eight plaintext bytes here, divided by 2, with an resulting 4. This wasn't
really satisfactory. The problem there was towards
the end I would have many many unknown records because I would was concentrating
on on the very first parts of the header. So the remainder of the key stream, the
very end of the key stream wasn't be able to being analyzed and eventually
decrypted. So I thought of something different. And there was something like a
I would call a byte histogram. So for every offset the MFT record, i would i
will then calculate creatin and a histogram and check how many different
bytes are there actually for plaintext, you know, it's a plaintext known plaintext
attack so I would need some kind of plaintext and would do that for every
offset for every record. And so these the questions there how to get many MFT
records - it's quite easy if you have some nice colleagues you just need to hang them
all of the balcony and shake them a bit then more or less voluntarily they will
give you some MFT keys to work with. And the result of that is quite nice: you, I
mean for for the very first, there's nothing much you can do the very first
record will always have very few sample bytes. But as the stream progresses and
you will have a dramatic change there so from this relatively low certainty of
four, I could increase that to more than thirty. So this is somewhat nice, and ever
bit of doing science, this table drops out from nowhere. So I compared these two
attack types. So, let's read that from from right to left. On the on the far
right, I have for the first approach about 98% of the MFT records being successfully
recovered. You know, with the good thing with science and with all this academic
approach is you have a ground truth. So I have a plaintext an unencrypted hard drive
which were virtually unordered from something right after infection, and then
you let execute the the whole infection and encryption process. And then you can
differentiate and take you knows several snapshots throughout the infection, change
different key values and all the stuff. So this is a very nice thing about this
academic approach I was taking the other So I could I could exactly pinpoint how many
of these records were perfectly recovered. So for the byte histogram approach I could
decrypt almost all of the records, which is quite nice because then we have a high
quality MFT to work with. What's also quite nice is that we have zero wrong key
stream bytes. What's not so nice, however, is that I was only able to recover about
1.3 percent of the overall key stream. And remember - this this key stream is about 4
megabytes in length and I was able to recover only 50 kilobytes of that, so we
can't recover all of the the files. Or is that so? This is this was my next question
there. And so I drew another nice diagram. This is the key stream; in the this is the
MFT, sorry, in the key stream. So the the key stream is only filled and in sample
bytes at this 2 megabytes mark. And the question is, are there many files in this
area being encrypted or is there some other bug I could exploit. And I checked
where the files would lie into this the key stream. So I would check how many
files are at which location in the key stream being encrypted. And you see the
key stream is used all over the place - so I mean sometimes it's used more, sometimes
it's used just the less, however, it's basically used all over the place. And so
this much of the key stream could in a perfect scenario be, I mean, perfect
scenario being a perfect known plaintext oracle could theoretically be recovered.
However, this is somewhat of a problem here and in the next part of the talk I
will present you how I was able to solve this problem as well. So remember when the
file system is actually encrypted by (Not)Petya, the file system looks somewhat
like this. So you would have the MFT which is totally garbled so you won't have any
of any nice file pointers or data runs pointing through those files. You won't
have any nice file names and all the stuff. But with the first stage being
finished, the MFT looks really nice - I mean like almost a hundred percent
of the records could be recovered. So it looks
somewhat like this. So you have a bunch of metadata you can now use to analyze the
the remainder of the files and the remainder of the encryption. So all this
MFT or almost always actually decrypted. And for files you would have the very
first kilobyte being encrypted. The remainder of the file, the, I mean, most
files are more than a kilobyte in size, right? So all the rest is not encrypted.
So you would have all this data and metadata to collect information and to to
use to exploit as-known plaintext as indicators for known plaintext. So I
thought of three different approaches to you know to attack this problem. Basically
I was thinking about: okay what different files are there, and I was quickly
thinking about different file types. And I mean, there are I mean the file type can
be easily gleaned from this, right? Because you would have the file extension
and it would be basically the file type. And you would have two different types of
files - you would have structured files and unstructured files. So I thought of
these and you would have something like, yeah, source code, which I would consider
as more or less unstructured. And I was calculating the histogram, so this would
give me some kind of prevalence towards different bytes in the key stream. So it
would be somewhat like a guest plaintext attack or something like that. The next
thing for structured files would be to do the very same approach as with the MFT
records. I would calculate the histogram for every offset of the first kilobyte,
and then quickly see how how many different bytes are there per offset. And
the last approach uses somewhat more data. It uses some of the metadata, and also
some of the file data. I will go into this right now. So, what I basically have here
as I said it's only this this little portion of the files encrypted. The whole
remainder of the file is not encrypted, which is quite nice. And also the file
name the file sizes not encrypted. So what I use, what I would do here
is create a database of known files of known
Windows system files, for example. Y'all might remember these nice background
images fonts all this stuff - plaintext is flying around everywhere if you just
look for it. And I would have basically three different, yeah, three three
different distinctors between those to know which which is the correct plaintext.
So there is this this key file name, the file size, and then the hash of this whole
remainder, of this whole tier. So if all these 3-tuple would match, then I would
consider this as a proper plaintext. However, there are some collisions, so
this is this is not really something that is straightforward. So the initial idea of
having of only needing to analyze the MFT and then could just being being able to
straightforward decrypt files needed to be altered a bit. So I added this database of
known files there, I added another another analysis stage in this nice box here, and
then I would be able to decrypt the files, eventually. So let's do a bit of science
and check if this approach would be worthwhile pursuing on a real-world
scenario. So let the science cat do its science, let me have a drink. So whenever
you did do here is to create a database of known files - I collected a bunch of
default Windows installations, which resulted in about 340,000 unique files in
it. Then I calculated, you know, the the different file type histograms I talked
about, I prepared my test setup, I added there 1000 different files. And you should
note that these files were not part of this known files database - they were
different from that because otherwise it would have been easy to do. Then I would
infect this machine and then let its encrypt by (Not)Petya and then attempting
recovery. And these are the results there. So, I did this with 4 different runs, so I
tried every approach separately, and then combined the three approaches. And the
outcome was something like this: So I would have only two files by the general
histogram approach being able to be to decrypt. At least 8%
where I will were yet decrypted by the location histogram approach. And by the
known files approach over 90% of the files could be successfully recovered. And even
better, the combined outcome would be almost all files being able to decrypt.
So, so much about academia. So the problem there is if you apply this to the real
world, you could get into more trouble there. And there was lots and lots of more
to think about so. There were, for example, non default windows installations
with the whole history of updates so this might be really interesting from a
forensics perspective. Moreover, there's lots of installed programs to derive known
plaintext from - for example, dotnet uses a vast source of known plaintext or JDK
installations. So, especially the JDK would would result in about tens of
thousands of different source code and HTML files. So this is this really was
really quite nice. The drawback there was, so there was so much data to collect, the
first attempts failed miserably because of the sheer amount of RAM I was using. And
this would would result in the admins constantly giving me more more RAM in my
VM so I would eventually end up with, I think, 128 gigabytes of RAM and my my test
VM. Also you have a much larger master file table you know because of all these
files that would need to be stored, so to put them in in comparison. So this nice
working prototype, so this nice test setup, I mean, would have an MFT of about
26 megabytes. And for real-world scenarios you would have something like at least 500
megabytes, and even MFT could be even like a couple of gigabytes in size. So this
means much more plaintext. So for through these really large MFTs you could quickly
recover the whole key stream, the whole four megabytes just by looking at the MFT.
And, in summary, this means that the decryption of (Not)Petya encrypted drives
is possible. So, for for the file systems the drives, I have looked at it, was
really I mean ever after having all these these first bugs out of the way,
I was able to decrypt and recover all the files there. So
there's a good chance the vacation photos can be recovered as well. And this will
conclude my talk, so quick summary - (Not)Petya has some severe cryptographic
failures and flaws, so I would only be able to call this LOLsa and not salsa
anymore. It might be possible to further look into this, this you know this expand
key and thing. It it has really really a bunch of more cryptographic failures in
it. I didn't look into that deeper but I know some of you guys are professors and
this might be a nice homework for your students to look at this (Not)Petya
implementation and check out some, you know, more advanced crypto analysis
methods. And you should note that this hook this this whole (Not)Petya thing here
I described the whole cryptographic flaws there are not just in (Not)Petya. They are
you see the brackets there: there they are in every each and every version of Petya.
So all of the drives that you potentially have saved can be decrypted. And so my
last point is if any of you or any of us falls victim to ransomware you really
should keep the drives. You keep them untouched in a locker and wait for a talk
like this basically. And then hope that someone comes around and then be able to
decrypt the drives and then, you will have your vacation photos back. So that's all
folks, thank you for your attention.
*Applause*
Herald: Thank you very much Sebastian. Now
it's time for questions, please queue up by the microphones.
Mic 1: Hi, well thank you very much for
sharing your findings with us. I'm from Rotterdam the largest harbour in Europe,
and as you might know, we were struck by Petya
Sebastian Yes Mic 1: Two terminals went down for a
couple of days, a couple of hundred billion euros of damage. Your approach is
quite theoretically, so now to practice - if you were there in this summer with
these findings, would you've been able to help us and decrypt the files and get all
the companies up and running again? Or is this too academic?
Sebastian: No, it's a practical approach I mean, I work for CrowdStrike and we had
some occasions where we were able to help the customers. So it's a very practical
thing to do so. And I was trying to insinuate this with, you know, this slide
here. So I was talking about the real world in this scenario. So I looked at
about 50 different encrypted hard drives with (Not)Petya, and I was able to decrypt
all of them, or most of them. Mostly the the ones not being able to decrypt or to
some, well, let's say, level 8 mistakes. Mic 1: Awesome. Have you shared your
findings with nomoreransoms.org? Sebastian: No, I don't know about this
site Mic 1: They provide decryption tools for
ransomware. Please do, thank you Herald: Microphone six, please
Mic 6: Thank you, in the beginning you mentioned that basically the key was
shortened to what was a 24-bit, something like that?
Sebastian: 26, yes Mic 6: 26, yeah. From that point, wasn't a
brute-force attack way faster and way more reliable?
Sebastian: Oh no no, don't get me wrong there. So the keystream length was 2^26,
so the keystream length was four megabytes. So you wouldn't be able to
brute-force that. So sorry, do you get that? The number of bytes was four
megabytes, and you couldn't be able to brute-force that.
Mic 6: Yeah but you already mention at the beginning that you basically shortened it
down to the possibility of at most two to the power of 26, and it is calculable.
Sebastian: Yes yes, I totally get the question. But you're you're missing the
point there. So it's not the key space, 2^26, but the key length is 2^26, which
would be something - I I'm not good at that converting this to decimal. Would be
something like, let me check, two to the... I mean, here, math guys, computer
guys: how many bits is that? [Inaudible audience answer]
Sebastian: Say again? Crowd: A lot?
Sebastian: A lot! So it's, I mean, it's it's four megabytes of keylength and you
couldn't just brute force that because you you would have each of these
four megabytes you would have to brute force. Got that? So the key is not 2^26
but the key length, the keystream length, is that long. Got that? So yeah, this is
the key space would be longer than the Bible. You know, and you couldn't just
brute force the Bible, the text of the Bible. I mean given enough time yes but
you know we will all know the stories with in monkeys and typewriters. I mean we can
talk about that that offline but you're you're mixing up two different numbers
there. Mic 6: Yeah I guess, thank you.
Herald: Questions from the Internet, please
Signal Angel: Does the MFT encryption work the same for Petya and (Not)Petya?
Sebastian: Yes, the underlying mechanism is the same. The cryptography differs in
such a way that the constants number is different. So, this little guy here - this
is different. It would be usually like expand key something-something. And here
it's invalid sect ID. So it's somewhat different, but the the MFT encryption; I
mean the the bytecode the and the algorithm is the very same.
Signal Angel: Thanks Herald: Any more questions? Then please
give a great round of applause to Sebastian
Sebastian: Thank you
*Applause*
subtitles created by c3subtitles.de in the year 2018. Join, and help us!