Yeah, hello, fustum.
Okay, so authenticated encryption in start system is the thing I want to talk about.
I don't know if any one of you knows what authenticated encryption is.
Just a quick shorthand.
So I think everyone here knows what ASXTAS is.
That's probably like the most common storage cipher.
You know, when you have used the encrypted default that it uses ASXTAS.
But, you know, from maybe some government regulation, you might hear that, you know,
the usage of a authenticated encryption or something like ADC cypress like ASGCM.
It's recommended, right?
Like when you use something like server-side encryption in S3.
For example, ASGCM is used by default.
And that's just an example of an authenticated,
or an ADC cypress or authenticated encryption in the system.
And what essentially happens?
What is the engineering challenge behind it?
Why isn't everyone using it?
That's essentially because we have something called the Ciphertext Expansion.
So when you encrypt, let's say, four kilobytes of data with ASXTAS, you know,
the encrypted standard, then you're 4K input, 4K output, or 4K be output, right?
But with using a authenticated encryption, we get an additional authentication tag.
You can think of it as something like an HMEC or like hash, right?
So when you encrypt, you're 4K by something, and you get 4K by it,
and let's say, 32 bytes of authentication tag.
And when you decrypt it, you need to supply this specific authentication tag with that corresponding data
to be able to decrypt it.
If you don't have that, if you know, this 32 bytes gets lost on the way,
then you have no way to recover your data.
That's how these algorithms are designed.
And the main reason why you want to use them or write, you know,
some compliance people say why you should use them is because in ASXTAS,
there's no kind of checking if the Ciphertext is actually valid, right?
Like, if I have a Ciphertext that's encrypted, something I don't know,
I flip a bit, I decrypted, and ASXTAS gives me the guarantee that the output will be garbage.
You know, we'll just be some random seemingly random byte screen, right?
And then kind of the system that's consuming that decrypted garbage has to somehow deal with it.
And at best case, it will throw an error and be like, oh yeah, I don't know,
out of order format or something, but it's not really a deterministic behavior, right?
And with AD encryption, you know, if you try to decrypt,
and the data, the Ciphertext system will be modified, then it will throw an error.
And that's essentially it. And the nearing challenge is storing this extra bytes.
So in S3 and object storage, we have this program, the problem is kind of solved.
And file system encryption that says standards like FScript, they don't use it at all.
Or as I mentioned before, DMcript also doesn't support it by default.
There might be some user space tools that use it, but as I said, like the big,
let's say kernel space encryption solutions, they don't really employ it.
Except in the Linux kernel, or I think also in 3BSD.
There are ways to use it, but it's always a little bit cumbersome.
For example, in a Linux kernel, you can use something called the encrypt,
the encrypt with DM integrity to use it.
But if you use it in a cloud environment, you essentially use your thin provisioning and
and resize and capabilities because it expects a set formatting that you kind of change afterwards for some reason.
I think that's a implementation limitation that can be overcome.
But it has yet been to overcome.
So if anyone's interested in that kind of topic, how to make storage more secure,
that's maybe a thing that you could look into.
So I'm really looking forward into the second talk.
And yeah, that's been my liking talk.
All right.
One could say too little.
All right.
Perfect.
Good.
Yeah.
I do.
I just put a Google Drive.
I hopefully better.
Yeah.
I'm looking.
Yeah.
So my button is very sticky for some reason.
I think it's actually in the.
I just edited it.
Oh, yes.
Yeah.
Nope.
It's the wrong one.
Okay.
Here we are.
At the bottom.
All right.
Okay.
Hopefully.
It's okay.
It seems to be working.
Okay.
All right.
I was in the center bit.
Yeah.
Perfect.
That works.
Okay.
So everyone.
I just wanted to give everyone a preview of what I've been working on for the last while.
Or this doesn't quite show the whole thing on here.
But I call this Hopnet.
And it's that.
I think the.
It's cropped.
Oh, the side.
The presentation is.
That's.
That's an.
Issues.
What do we have here.
It's hot.
I've seen.
Okay.
And we want.
Probably.
Who does run.
Oh, sorry.
You got to see this one.
Okay.
Thank you.
Okay.
Thank you.
Okay.
So this is something I've been working on for a while.
But I haven't previewed it.
Yeah.
So I call it Hopnet.
And the basic idea behind this is you install it on any device and organization or group.
And the device contribute storage to the shared pool.
Maybe you've heard this before in distributed storage.
And the key difference here is you interact with your files just like Dropbox or Google Drive.
And there's intimate encryption, which is two things that are not really taken.
As design considerations and a lot of other systems like this.
So just to give you an example of what that looks like.
We have a web server that you can use by Dropbox if you want to download the files.
But also, crucially, the OS integration.
So we use the Apple file provider API, which is sort of very indefinitely integrated with the operating system and materialized as files.
With APFS, thin copy is without sort of you needing to think about what is on the device.
This is not in course being distributed.
It's very high speed as well.
So you can quickly download things.
It's also an Android version of this integration and an iOS version.
And I'm going to be working on an FA Notified hook for extension to Linux, which I'll give you a bit later.
So the overall vision is you have to load your data in one place and one device download it somewhere else.
And you can just access it in your finder and whatever explorer you use depending on your operating system.
Just like Dropbox.
It's very, very convenient.
And also programmatic access, which not currently as incompatible, but something like that eventually.
And so the redundancy design for this, it's chunk to read Solomon.
We have streamed uploads and downloads.
And if you have used read Solomon, you know that it's kind of difficult.
You need to get all if you lose the original fragments.
You need to get at least the size of the file to recover things.
So we split it up into chunks.
The max chunks I was 14 megabytes and inside each chunk.
Then split into 10 fragments.
10 original fragments and 20 recovery fragments.
So that's four megabytes of max recovery for fragments.
If you're doing the math there.
And then distribute them with each fragment index i,
a place in the same node for all chunks here to n.
So that means that you get the same redundancy characteristics.
As you go with full file read Solomon.
Which guarantees, you know, one in free.
If you have a free note network value, a maximum of 20 failures with this number of fragments hot-coated.
And so that enables streaming file access even if original file fragments are lost.
And this is really important when you're using things like the file provider API.
Because it does provide like a posics compatible API there.
If you're going to terminal and you type like cap a really big file,
it will just start to output it and it will just keep dumping to the terminal.
As it downloads from the other devices in the network.
So you get super high speed performance.
If you've got like a 70 gig video in there, you can just stop playing it back immediately.
And yeah, you want to need that first chunk to stream the file.
So even if you lose some of the original fragments,
you just occur a maximum of 14 megabytes.
Time to first bite out of the system.
And it also scales quite nicely.
These hot-coated number of fragments.
Free node network, one in free to survive.
20 nodes max value.
It was probably okay that hot-coated 20 recovery fragments, even large network.
We've regards how this all works.
Synchronization wires.
It's got a two-phase Byzantine fault tolerant consensus state machine.
So it's a derivative of hot stuff too.
If you're familiar with distributed systems there.
But it has a dynamic Byzantine fault tolerance approach.
So of course the start-up problem is really complex in BFT systems,
where if you only have less than say seven nodes,
which is the requirement for like two-end customer recovery,
you need to get that many nodes.
It doesn't work very well with consumer hardware.
This allows us to fall back to majority rules that we have less than seven nodes.
And then you get those BFT safety guarantees above seven nodes.
And it also has a dynamic validator set.
You can notice what automatically votes out and vote back in.
Nones that go offline.
So if you have roaming hardware like laptops,
really good for that.
Of course, there are a lot of security considerations that we've regards to DDS
and that kind of thing, which is something that is still being worked on that.
And per node state, the consensus is decoupled from file operations.
So basically if you upload a new file or a modification to a file,
the hash gets propagated to, you know,
if it's consensus system before the fragments actually finish the distribution.
So that happens to be synchronously from the actual state machine progression.
So it's a good for highly concurrent uses.
If I upload, if I update a file and someone else hasn't yet sort of seen,
or fetched the fragments of that change,
they know immediately that the change has happened.
And their device, when they double click it,
will, you know, make the call of, you know, send calls to other nodes,
APIs, to fetch the fragments from them to reconstruct the file,
rather than them working with an outdated file.
Each node maintains a WDB representation of the global file system state.
And the consensus is basically just tracking transactions against that database.
And so we've regards the encryption security architecture,
file paths are encrypted with ASSIV, which gives us deterministic encryption.
So at each level, you can basically use, like, a find where in this encryption level,
if you want to find all the files in a path without having to do,
you know, really slow, treat reversals for things to find what is in this path.
And that key also is just tied to the users,
ED25519 identity.
So you just roam with this one thing.
I've been very interested in web crypto.
I've rolled out some ED25519 sort of support recently.
So, you know, that has some interesting things for, like, web architecture,
of decryption.
They keep going, um, no.
That's the rule.
OK.
I'm going to pause the talk next year.
Yeah.
Sounds good.
Thank you.
All right.
We have...
Joe.
Do we have Joe?
Yeah.
Of course.
All right.
So, does anyone here have heard about Solida?
No.
I've heard everybody.
Oh, yes.
Can you get the microphone for you?
Oh, yes.
Sure.
OK.
Yeah.
There is a lot of name for Sol.
So now, it's my turn to do some,
X-Render magic.
I have a script for that, Molly.
Probably won't work.
Uh.
Oh, wow.
OK.
Yes.
So, I'm going to present Solida as fast as I can.
So, basically, Solida stands for social link data,
and it's a project initiated by Tim Berners-Lee,
the inventor of the web,
who are like, I build this web for like,
a utopia of share,
a decentralized share knowledge,
and why it becomes this dystopian of capitalism of surveillance.
And he's like, a bit sad of what his invention has become,
like, like, for understanding a little bit.
So, he was like, how can we solve it at a design level?
What, what when the book in the architecture of the web?
Uh, and his idea is that when you use the web web app,
it's always application who stores the data.
And, and this is what went wrong because it,
it allows the app to capitalize on data.
And this is the new goal today, right?
And the most, uh, richest company are based on user data.
So, he's like, maybe we should allow the,
the, the, the user to store the data where,
where they want and to have those app that we can call,
like, zero data apps that just like fetch the data,
do whatever they want,
and then put it back where's the user wants.
So, that's the idea.
Uh, it's based on W3C's standard,
and it's just like a extension of web standards,
like HTTP.
It's based on link data.
So, basically, link data,
it's a way of storing data in triples,
where you, uh, every, uh,
item is a full URL,
and you define relation between data.
So, for example, if you have, uh,
artist called Mona Lisa,
you give it, uh, this is your subject.
You give it a predicate,
which is like, which, like, the artist.
So, who created this, this, this,
the, the, the, the art,
and then the object is like Leonardo da Vinci,
and it's allow you to,
to have to create this massive graph of knowledge,
and it's really cool to, um,
it's a really cool way to store data,
and it also allow to have, uh,
interoperability,
which is essential in the solid project.
Uh, so, yeah.
So, the goal is to give every user,
a pod, which is a personal online data store,
and you see it as a third-party database
that every user have,
and, and, and can connect to application.
And the application will,
will store the user data in a pod, uh,
in a link data format.
Why in a link data format?
Because this allow,
well, I went a little bit, uh, high energy.
Uh, it allow, um,
so for example,
if you, like, in a solid world,
if you want to switch, uh,
from Gmail to Potomale,
um, and, and assuming like,
all user has a pod,
you just, uh,
remove access from Gmail
to your mail folder,
and you contact folder,
and you allow Potomale to have access
to your pods, um,
to your pod,
a mail and contact folder.
So this is really cool, uh,
because you just,
handle,
and then, on Potomale,
you have all your contact,
all your mail, you have all your data exactly the same.
Because they are stored in the same place,
and also because they are stored in
link data, which allows this interoperability.
Okay, we don't care about this, uh,
uh, yeah.
So how does it look?
Uh, that's the workflow.
So on the left,
we have a, uh,
that doesn't store any data,
and on the right,
we have a solid server,
which both has the database,
the user database,
and the identity provider.
Uh,
you as a user to sign in,
it gets redirected to the identity provider of the solid server.
The user identify,
uh,
and then the app has,
like,
all the,
the permission,
it needs to fetch the data.
So now we are assumes that in the,
in the user pod,
there is some task,
and it will know with some,
uh,
standard,
uh,
like,
it will know where to find the task,
and it will,
uh,
return it in the,
in the app.
And, uh,
yeah,
I think the,
I, I just,
build this,
uh,
last minute.
So, uh,
this is a presentation for something else.
I think I'm done with my points.
Uh,
if I have a few minutes remaining,
I don't know what to talk about.
30 seconds.
All right.
Well, uh,
thank you for, uh,
for listening,
if you are excited about this,
as much as I am,
because it's really cool as a web developer
to program with solid,
because basically the user come with,
with, with a,
with a full,
like it's like an abstraction of a,
of a back,
and you can see it, right?
So you just have to build a front and up,
and you imagine that the user already,
you already have authentication,
and data storage.
So,
it,
as a web developer,
I think it's super excited to,
to have a web where we,
we can,
we can have that,
and,
all right.
Thank you for listening.
All right.
Yeah.
Did you put yourself in the document,
I think?
Oh, okay.
Sorry.
Okay.
So then,
the size of the web developer?
Demo?
I think that's not really lighting.
All right.
All right then.
Hopefully this goes quite quick.
But,
hello.
Hello.
I'm glad you could hear me.
So,
this is based on the talk that I have given a couple of times before.
the time is before. Hopefully this works out. Hello, my name is Gwendoz. I work for the University
of Cambridge and I do Luster. Luster, it's... Oh, oh, Cracky. Let me grab my laptop.
Huh? I'll see if it'll be starting to fall right now.
No.
Oh, I did it.
Set this wax.
Okay.
I'm parking.
That should work, maybe.
Is that going to work? I don't know. Let's see, shall we?
It's certainly maybe I can do the thing.
Oh, that's annoying.
That's encouraging. Excellent. Come on. Come on.
What's green? Can you do it?
Go on. Stupid laptop. No.
Oh, bloody thing.
I hate this machine.
It is.
I need to get out of my solid surface otherwise the mouse is quite properly.
Come on. Come on.
You know, I'm time now.
That's what I'm going to say if I can get it to.
No. If I've all screened, it doesn't work.
It's probably the zero zero on that screen.
Otherwise it thinks it's still on the other.
The top left corner.
What are you talking about?
Try to top left corner. The window needs to be on the external screen.
Oh, I see. Yes.
So it's the top of the way to get on the screen.
No, I saw it.
Not that.
Because it takes a moment for a reason.
It's then you don't have to deal with that.
Yeah, tell me about it.
This is so awful.
I really hate this machine.
I'm hoping I can successfully manage to get a nice one soon.
Otherwise, you can press the windows button to shift with it.
And then let the right.
We have those.
Nice try.
Oh, this is annoying.
So I can get this work again.
How? How annoying.
I do indeed.
That you're so so irritating.
I really don't read them to us.
I need to get a replacement laptop.
Yes, of course.
So fine.
Fine, fine, fine, fine, fine.
So hello.
Hello, I do lost it.
Luster is a also soft and fine storage.
But Luster is built quite differently.
It has very little away of software defined resilience.
It primarily works on having all of that resilience put on to its hardware level,
which is great if you want really serious performance.
I have some really serious performance numbers.
Can't show them to you.
It's going to get the slides to work.
Because I might have to open that great.
So I'm I'm part of being administering a door, which is one of the UK's super computers.
We've been working on the big Luster file system for it.
So we can provide storage to AI workloads.
AI workloads need lots of performance and very low latency.
And basically as much as you can throw as it.
How do we do this?
Well, we use a large quantity of NDMAs to be able to provide the actual base storage layer.
But of course most NDMAs that about these days have no resilience at all.
So combination of software that doesn't provide any resilience and hardware that doesn't provide any resilience.
It's kind of a bad time.
So we've put some extra software on top of it to be able to.
To provide that storage in a way that is able to deal with the blast radius of users to make sure that it's suitably sort of handled to them.
So we we use slum because we I'm HPC.
So slums are scheduler and as a scheduler that means we can control where I use this.
But the data and we make sure that I the usage of our data relates to how much they can lose.
So we have a carefully crafted construction to make sure that it's actually capable of handling the lack of resilience.
And that's yeah that there's something that we can translate to our users.
What's it's kind of difficult because everyone sees the posit's files system and thinks that every posit's files system is going to act the same way.
And they don't they very much do not, which is kind of fun.
And really difficult to describe to users.
But doesn't go fast yes it goes fast.
If you treat it the right way around.
The fundamental problem is.
The.
Correct you.
It's in my slides away.
If you do not.
If you run through the page cache.
You we actually find winning it about 20% performance.
So we have potentially 100 gigabytes per second on these machines and that's per note.
If we don't if we actually if we don't use O direct so we use the page cache we only get about 20.
But we can get it to about 85 gigabytes per second.
If we turn off the page cache and use O direct instead.
And it turns out then in last 2016 there's a thing called hybrid I owe that does that automatically for you.
So you don't even have to get the users to understand what O direct even means.
This isn't that nice.
So in a nutshell without my slides.
That's pretty much the subject that had isn't that nice.
All right.
Anybody else interested in coming up here for five minutes.
I guess not.
Well then thanks everybody.
Hope to see you next year.