[Music]
good morning our next presenter is alexa
saray he's a core developer and
maintainer of runsi and umachi
contributor and maintainer of open
container initiative specifications and
a linux kernel contributor
he works on the containers team at suse
alexa will present
his
talk in a pre-recorded video today and
remain online for any questions that may
occur during the video or at the end
now
pass it over to the video
hello everyone my name is alexa i'm glad
you could make it
today i'll be talking to you about
paperback which is a digital will and
backup system that i've been working on
well i sort of came up with the design
in 2018 and then i worked on a little
bit here and there but the project has
really come together in the past year or
so um and yeah so this is completely
related to my regular day job i normally
work on containers um but this is sort
of made this whole particular problem
that i had um and hopefully it'll be
interesting to all of you i'd love to
hear your thoughts and opinions on this
um and i would love to get some
assistance with some of the bits that um
i'll talk about at the end of the talk
um so why do i say will end backup
system uh well as you'll see in a second
um it actually turns out that both of
these problems the problem of how to
deal with um wills and backups with
digital assets in terms of it turns out
that they have very very similar issues
um and so we'll go into that right now
so
the first thing to consider is when it
comes to wills now before i start i
should say i'm definitely not a lawyer
not even slightly um and so anything i
say here um is not actually legal advice
or anything um you should definitely
speak on actual lawyer about wills um
but at the moment there it is actually
practically like quite difficult to deal
with digital assets and wills um the
primary reason being that for most
digital assets there isn't really a
legally mediated media method of
transferring um some sort of digital
asset between people um you have some
online services where if you have a
death certificate and you have um an
order or whatever from um from the
executive of the estate you can actually
uh transfer just less between people um
but in many cases you have terms of
service that allow you to even transfer
accounts um and then you have things
like cryptocurrencies and stuff like
that where um there is not even there is
no mechanism to do um
to do a transfer even if you did have
all of the legal um even the legal right
to do the transfer um and so as a result
the sort of solution that he gets thrown
around is you want to well okay just put
your passwords or put your keys or
whatever in your will and then that way
when you know when you have the executor
of the state they actually have the data
that's necessary um the problem with
this is that uh it relies very very
heavily on lawyers and the opsec of the
lawyers and this is quite a unique
problem digital assets which doesn't
apply to regular assets i mean if you
think about it like when you're saying i
will leave my house to my sister claire
and to my son peter i'll do yada um
these
um that sort of case is like for
physical assets uh the the fact that you
have it written in the will is not in of
itself enough information to steal it
like just because it says that you will
give your house to xyz does not mean
that
that the info that information itself is
enough to actually steal the house um at
least you would hope not and so
therefore this is sort of like a fairly
new problem in that the will um maybe
the world might be secret but the will
itself even if you did have access to it
does not actually give you access to
steal whatever it is that's in the will
um and unfortunately for digital assets
is not the case for digital assets in
many in many cases um the information
itself is the thing that is enough to um
to take it and so they've unlike most
secret sell by lawyers um you have the
problem of it's sort of a unique
ownership system where having the
information is usually enough to say
that you own it but also even in the
case of cryptocurrencies and things like
that um even if you could prove that it
was stolen there is no practical
resource recourse for theft i mean if
someone steals a house you can always
you know repossess it like it's not it's
not um gone forever this is not the case
for cryptocurrencies and i mean there
are other examples where cryptocurrency
is the most obvious one um and i mean
hopefully you trust your lawyer if you
don't you should probably get a new one
um but you should also know that there
have been thankfully rare cases of
lawyers themselves selling money from
clients um if you think of someone who
has a lot of money in
cryptocurrency wallet or if they or even
if they have a very very valuable
digital asset of some kind um you're
you're sort of um you're in you're in
big trouble if your lawyer decides to
just take it from you um but as i said
i'm not a lawyer speak to an actual
about wills i suspect that paperback
itself um probably can't be used as a
will unto itself uh because i don't know
there's probably some sort of common law
restriction that makes it not possible
to use it i'm not a lawyer but um
i suspect that the only way you could
really use paperback for an actual will
um would be if you were to take um you
would create you were to draft the
normal will and then in that well you
would reference a paperback backup um
for the actual data required for digital
assets i suspect that's how you would
actually end up using this um but again
speak to your actual lawyer if you
actually do plan to use this for a real
will um so the rest is talk i'm not
going to talk about wills um i've only
mentioned it here because as you'll
notice this this sort of problem of well
we need to have a way for it to be
recovered if i'm not there this sort of
problem actually is is very analogous to
a problem with backups um so there's
something about backups but just keep in
mind that these two problems are
actually um fairly similar at least in
this particular case um so we'll go into
digital assets and backups so there's a
very similar problem um with
backing up a digital asset which is that
okay you have um some sort of key or
something so so you have a secret and
you want to have it um be safely backed
up so you want that secret to be
distributed because if you were to just
you know put that secret um like printed
out unencrypted on a piece of paper well
you can't give that to your friends
because now your friends have access to
um
to the particular thing that you that
you that you're trying to protect and so
you therefore want to either you would
just have one copy that you keep in your
house but then if there's a house fire
the backups are basically useless you
know you have the original and the
backup both get destroyed
so instead you would want to encrypt it
but then you have the problem of well
how do i pick a key that is strong
enough such that if i give this to my
friend they will not try to just uh to
break it or if they tried to break it
they would not succeed um but if you
have a secure enough key now you have a
problem of well i'm not gonna be able to
remember a key that is super complicated
um maybe i'll remember for a year or two
but i'm not gonna remember of 30 years
uh which is the sort of timeline you
have to think about with with certain
types of backups um because you probably
don't want to be recreating a new backup
every five years and annoying half your
friends you know who knows where they
move to um so yeah this this this is a
pretty big problem um and obviously now
you have the same opsec issues you had
before except now it's not it's not your
lawyer's upset or your lawyer's office
is upset it is your op second the
opposite of everyone um everyone you've
given a copy to just to give sort of the
flavor for why i've originally started
working on this problem um so i have a
home so you actually probably can see it
in the background um that runs you know
next cloud and a bunch of other things
and it has all of our legal documents
and all of our photos and absolutely
everything is uploaded there um
obviously pretty important stuff and so
i use a tool called rustic which is by
the way pretty cool if you don't um if
you're looking for a cool ingredient
backup solution rustic is pretty good um
uh it works pretty well and i've never
had it i don't have any i've not had any
issues with it um
so yeah so i use rustic um for encrypted
and duplicated backups um with a key
that i don't know and we'll get into
that in a second so there's a fully
randomized key the server has that i
don't know um those those backups are
encrypted with that key and then the
backups are uploaded daily to backblaze
b2 which is um you know some online um
you know uh storage service um could be
uploaded anywhere um but yes but in
order to recover my backups i need that
password which i don't know and so if
you imagine sort of the recovery
scenario we're dealing with well okay
everything gets destroyed um all of my
devices get destroyed my server gets
destroyed everything except for the um
online backup i have which is sort of
like the most extreme disaster scenario
you can imagine but surely a backup
system should be able to handle this so
in this situation i now
i don't know my i don't know the key
phrase because if i had a simple key
phrase that would be prior to attacks
right like my while you know my upload
is password protected you know it's sort
of still out in the open in in a sense
um so i can't use a simple key because
that's prone to attacks um but if i use
a complicated key then uh i need to have
some way of backing that up because i'm
probably not going to remember that for
you know for the rest of my life um and
then you have sort of you can see this
sort of quickly becomes an infinite
recursion if you have a complicated key
and you need a backup for that key how
are you going to back that up and sure
it's less data to back up i mean
presumably but you know it's still
something that you now need to figure
out a way to recover so the solution to
this problem where i should say our
solution to this problem is a scheme
developed in the 70s by shamir um the
snrsa called premier secret sharing um
and so i'm going to go through sort of
the nuts and bolts of how this scheme
works um you don't have to swear that if
you if you don't quite get it um the
mathematics is sort of like uh first
level uni um high school of mathematics
but it does take a little bit sort of to
understand what's going on um so if you
don't get it no worries um i'm sure that
if you went in through the wikipedia
article it would all make sense um so
i'm going to give you the quick overview
because while it's not necessary to
understand how paperback works um it is
useful to understand how the scheme
works so that you can understand how
some of the other features work um so
yeah
so the general gist here is that using
some fairly rudimentary algebra which
i'll get to in a second you can take any
secret you like and you can split it
into k pieces so it should require at
least n pieces to recover the secret and
this actually has some redundancy built
in so you can have nnk be different
numbers you can have it such that you
require five pieces but you make ten and
that way even if you lose five of them
you can still recover and you can use
any of the five as long as it's five
unique pieces um and the key the key
thing about shamir's approach um
compared to sort of like an av different
approach is that the unique thing about
this scheme is that an attacker with n
minus one shards has no more information
than if they had zero shards um the
scheme actually has perfect security
similar to one time pad and the reason
for this is sort of um i'm the
cryptographer so i can't go into the
mathematical proof but the way i
understand is basically um
given nmis1 shards i can construct an
additional nth shard that produces that
can produce any arbitrary result um
meaning that uh even with n minus one
shards the nth shard can be anything and
the result can still be anything meaning
that you have no more information from
an information theory perspective um
then you've got zero shards um which is
kind of interesting and um
therefore the only requirement of the
security system is that uh you pick the
n such that it is big enough such that
uh you can be sure that of the people
you hand it to um less than n so up to n
minus one but less than n will conspire
against you um and as long as you have
that then you then the system is is has
perfect security um assuming it's
implemented correctly and all the rest
of it um so
the the only real mathematics you have
understand to understand how this system
works is um this part of my fact is
called lagrange polynomials um but the
general idea here is that
um
uh is that for any given set of n plus
one points um there is a unique and
thought of polynomial that goes through
them so there's only one given any n
plus one points um and the flip side of
this is that in order to reconstruct the
equation of any nth or polynomial you
need n plus one points from that
polynomial um which is like x y
coordinates of that of the polynomial um
and what this means is that
any system of uh what's called
polynomial interpolation which is a
system by which given points construct a
polynomial that matches them um any
system of polynomial interpolation will
give you uh the correct original
polynomial if you have n plus one points
because there's only one so if it is
giving you an accurate result it must be
giving you the same polynomial um and
that's what this system depends on so
lagrange polynomials are sort of the
most straightforward way of doing
interpolation they're not the most
efficient there are more efficient ways
but it's sort of out of scope for this
discussion um the general idea is that
you can use lagrange polynomials for
this particular use case um and the
mathematics is pretty much pretty
straight forward
um and so what is your message sharing
shame secret sharing is an application
of lagrange interpolation or any sort of
polynomial interpolation um by what you
do is that you take is that you
construct a polynomial so first you
decide okay i want to have an nk scheme
where you need n k end points so you
construct an n minus one degree
polynomial remember you need one extra
point so if you require five points you
make a four degree polynomial and so on
and so on um so you construct an n minus
one degree polynomial uh with completely
random coefficients
except you make the secret so the part
sorry you make the um constant term
which is the part that has an x value
you make that the secret and therefore
when you evaluate the polynomial at x
equals zero you get the secret and then
what you do is that you give each person
an x y pair where x obviously isn't
equal to zero you give them an x y pair
and then um that's their pieces you can
make as many x y pairs as you like and
then you
hand them out and then in order to
reconstruct you just need um end points
using lagrangian triplication or any
other polynomial relation um and the
cool thing about this is that as i said
this is perfectly secure
but it has to be done in finite fields
it turns out that while theoretically
you can have an infinite number of
polynomials because polynomials have to
be um have to have smooth curves
there are practical limit basically
there is a there's a theoretical attack
or attack you can do if you don't use
finite fields but in finite fields this
is um this is perfectly secure
and the reason why again is because um
there is an infinite number of nth
degree polynomials that pass through any
given set of endpoints so if you have n
points which is
one less than the amount you need
you can pick any point you like as the
as the final point and it will give you
an arbitrary polynomial um that's the
reason why it has perfect security um so
one quick a couple of words of warning
um while perfect security sounds really
nice um uh it's sort of like a one-time
pad in that the fact is perfect security
does not necessarily exempt you from
anything else um you have to be aware
that it relies on working code um now
what this means is that uh now it's sort
of obvious that it relies on working
code but it actually turns out that
there is no really standard widely used
library um that is well audited for
schmidt circuit sharing there are a
couple that are used by different people
but they're but they're all pretty much
um abandoned i would say there are some
that are they get more development than
others but there is not really like one
library that everyone uses like there's
no open ssl for secret sharing um and
the secondary problem is that a lot of
the libraries i looked at had some sort
of critical flaw now some of them had
less
severe flaws or had like design
decisions that would problematic for
paperback um the most common one being
that they all seem to use the rsa
gower field this is getting a bit
technical but basically what this means
is that if you use this field which is
sort of an obvious field to use it's the
same field that rsa uses
the problem with using this field is
that
you can only have 255
coordinates x coordinates because it's
um because uh it's two the gauge field
is two to the eight meaning there's 256
possible x values and you can't use x
equals zero so you have to use um x from
one to fifty five um the problem with
using such a field
is that um sorry 1 256. um the
probability field is that uh
okay maybe you don't want to make 255
pieces but if you want to generate a
random x value you can't because the
chance of collision are way too high um
and so you need to have a bigger field
but unfortunately most of them just use
um the 2d8 the the rsa field
which is a bit of a shame um there were
however there were some that had
critical flaws um i'm not going to name
names because they fixed it but
basically there was there was a floor in
one um library where they mistakenly um
the way they initialize a vector was not
ideal and basically what they're
happening is they made it so that every
single um
every single
sharing that they created um i i believe
that the bug basically was that um it
was always a degree two polynomial which
meant that every single no matter what
you asked for it would always have a
threshold value of three um which was a
bit of a problem now they fixed the
sense but it's sort of an example of the
kind of problems you need to avoid um
yeah and so the other problem is is that
uh this sort of by design shimmery
secret sharing requires a secret to be
in a single place both at the creation
and recovery time um and depending what
the secret is this might not actually be
safe for you um you can imagine cases
where like well how do you know the
computers have malware on it um you
might be the case well okay well i want
to have um again sorry to keep going
back to cryptocurrencies but the
cryptocurrency example is like well okay
i generated an offline uh key on my
hardware wallet i don't want to be
putting that onto a computer to generate
this thing um yeah there isn't really a
solution to this it sort of really
depends on what people need what people
want um yeah so there is a potential for
single point of failure creation and
recovery time if that's not applicable
to you then um then you should know um
and in addition if you do recoveries
often uh each recovery you're sort of
having the secret in a single place
that's pretty bad if you have to be
doing it like once a week or something
um if you need your recoveries often
there are almost certainly better
solutions um for bitcoin there's
multisig which is basically you can
construct a threshold scheme which
doesn't require having the secret in one
place instead you have multiple
signatures for the same thing um
obviously that doesn't help us in the
backup scheme this is just purely useful
for people who use um bitcoin or some
other cryptocurrency um but that's sort
of an example of saying where there is
another solution that is probably better
suited for certain cases um but for the
will and backup scheme probably this is
this is what you want you probably want
paperback
and so then this takes us to paperback
um so paperback is an application from a
secret sharing but um it has a couple
other things added to make it easier to
use and also to um avoid some of the
pitfalls with with using shimmy secret
sharing and nothing else so the general
idea is is that we take your secret and
then that secret is encrypted using a
charge20.1305 key that's randomly
generated um and then that gives you
your main document so the main documents
there are two pieces there is a main
document and there are your key shards
the main document is the encrypted
version of the secret and then the key
is then split using secret sharing and
then given to the to the um shard
holders now uh there is also a signing
key generated and the the reason for
this i'll explain in a little bit um
basically it's going to do with um
forgery detection but effectively there
is also a signing key added and that
signing key is then used to sign all the
documents and all the documents contain
a copy of the public half of the signing
key um but the private half of the
signing key is included with the secret
um the reason why it's included is so
that we can um create new shards after
the fact i'll explain why i'll explain
how that works in a little bit um so
that's the general idea um and in
addition to that all of the documents
contain a copy of the main document hash
again to avoid um forgeries to detect
forgeries um and yeah all the hashes are
blake to be 256 and if you want to read
more about the threat model and exactly
how the scheme works you can go read in
the repo there's a design document that
explains everything in pretty great
detail
um so this is what the payback documents
look like so these are the mock-ups um
i'll explain a little bit why i'm
showing you the mock-ups um because i'll
show you what the real documents look
like at the moment in a little bit but
these are the mock-ups but it's easy to
go through the mock-ups because they
have all the bits that will be in the uh
full version um in a little bit in fact
by the time we're talking probably the
mock-ups and the um original version the
version generated by payback probably
look the same um but yeah we'll go
through them so first you have the main
document header
which contains a couple of critical
piece information so first this is what
it is main document um and then you have
the paperback version that was used to
generate it um and then you have the
document id and then you have a
description of what's going on the
document id is actually based on the
checksum um it's the last eight
characters of the checksum um which
means that even if you end up with
forgeries and all the rest of it as long
as someone remembers what the checksum
uh what the document id was um it's
unlikely you're gonna be in a situation
where someone will be able to trick you
into thinking that a different document
is the right document um but yeah anyway
so the main document has this is the
main document up here about backup and
it tells you how many key shards you
need as well as how to recover it go to
this website and all the rest of it um
and then yeah so then you have the
document section so the document is
encoded with several qr codes um the qr
codes uh while they have arrows here um
the qr codes can actually be scanned any
order because the qr code contains
information about what qr code what
index is it in the list of qr codes as
well as how many qr codes there are so
once you scan one you actually know how
many there are or paperback knows how
many there are and then it will tell you
which ones you have scanned which ones
you haven't scanned um and then the
checksum the checksum as i said um it's
just a regular blade to be strict some
but um the last eight characters in this
encoding are then used as the document
id um to make it so that at least it is
possible to detect a changed document um
where the checksum has changed um you
better attack because the document id is
different then you have the key shots so
key shards are um sort of laid out the
similar way except they're green um and
yeah so key shards it says what it is
this is the version it has the document
id listed on it so that you can match up
match them up with the um with the
document um it should be noted the
document hash the full hash the document
is included in the key shard as well but
for the human readable portion it just
has the document id
and it has the shard id the shard id is
actually not
from the checksum because
the strategy is actually the x value um
of the of the um of the share uh the
reason for this that the x value is
actually small enough with the scheme we
use that you can just put it there and
also the x value is arguably a better
way of determining uh which sides are
unique because if two shards have the
same x value then they'll have same y
value which means we can't use them for
recovery um and yeah so that's how it
looks um it should you should be in
there also you might notice that um
uh we don't say how many key shots you
need this will be obvious in a second so
you have this bit which is the keyshot
data um there is the qr code and then
there is a text fallback to type out um
we can't do this for main document
because the main document obviously is
very it'd be very inefficient to encode
it like this but because the keyshot has
much much smaller data payload we have
the um the encoder version um the
encoder version should be noted um we
use uh what's called zbase 32 for the
encoding of the text fallback um which
is meant to make it harder for people to
when you're reading um to mistake one
letter for another
one character for another um but should
we know the qr code itself actually does
not contain the same encoding and it
contains the same data but does not
contain the same encoding um because i
discovered that if you try to use like
zbase 32 um or like any sort of
alphanumeric um encoding and put it in a
qr code it actually takes up more the qr
code takes up more space like it is a it
is it has a larger data payload because
of how the encoding works inside qr
codes so the qr code actually uses um
alph uses just base 10 encoding um it
turns out that
this gives you almost as good as binary
encoding we can't use binary encoding
because data itself is binary encoded
and um it's like it has null bytes and
things and readers don't like null bytes
and you can't copy null bytes so we use
um just a numeric base 10 encoding which
gives us as basically as close as you
can get um and and payback can can
distinguish the two because we use
what's called multibase which is um
basically it's a prefix for every single
um encoding so we can tell which
encoding it is which is kind of cool um
yeah and so that's that and then you
have the checksum which is again a
regular like to be checks on and then
you have the code words so actually this
key shot itself is encrypted so there is
a second level encryption of the of the
key shard contents and the reason for
this is that it gives the option for key
shot holders to add a little bit of
extra security um by they can optionally
cut off this section and then either try
to memorize it which i wouldn't
recommend or they can store it
separately so they can have the data
section and the um code words for the
key shot in in separate places such that
even if someone managed to break in and
steal one of the pieces it's useless
without the other piece um this is
entirely optional i suspect most people
probably won't do this but you know it
doesn't really cost anything to add this
um and you know people can people can do
it if they like um and yeah and the the
um the
code words are using pip32 um
and also the codewords obviously it says
which shard and which document it is so
that it's easier to to match them up um
if someone does decide to cut them off
so a feature that paperback has which
sort of sets it apart from most of the
shma secret sharing systems is it has
support for each which i call um quorum
expansion now what this feature does it
see this is actually an application of
how many signatures works like the
mathematics of it so this is saying
which technically any html secret
sharing system could support but i'm not
entirely sure why most of the systems
don't support this probably because it's
a little bit inefficient to do um but
the general idea is is that uh what
happens when someone loses one of their
key shards so here we have a globally
distributed set of key shards you have
um you know four people in australia one
person in europe one person in canada
and what happens when uh one of the
people in australia loses their key shot
well you can do there's a naive way you
can solve this in a less naive way which
is the way that paperback does it so the
naive way of doing this is that well
okay luckily there are three people in
australia and this scheme only requires
three people to recover the secret so we
can recover the secret decrypt the
original document take the secret from
the document and then we can um convert
a new document and then give every
single person a new
key shard and
the
problem with this system is that this is
very inefficient when you have a lot of
people and if you have people who are
very globally distributed you might find
it quite difficult to actually be able
to share this with it share the key
shots with everyone um and obviously
when you get even more people it becomes
even more ludicrous in terms of how
inefficient the system is
so luckily um you can actually just take
advantage of how the polynomial system
for for um
securing works so um just as we are
using the x equals zero interpolation to
get the original secret um the reason
why using x equals p x equals zero is
purely because it's more efficient to do
it with x equals zero but you can
interpolate any x value you like um and
thus if we have n shards we can use the
same interpolation we're already doing
but rather than evaluating x equals zero
we can evaluate some other x which will
give us a new key shard which is
compatible with all the others
there are there are more efficient ways
of doing this um uh which i won't get
into now but this is the general idea is
that you can use the same interpolation
rather than just interpolating x equals
zero you can interpolate at any other x
value um you can actually even
reconstruct the entire like all the
coefficients this isn't actually this
isn't necessary um but you could also do
that if you wanted to um but that's even
less less efficient
and so using that we can then take
advantage of that where we now have the
same situation and then we have three
people um who then come together for a
quorum and then you can just create a
new key shot just for this one person
you can either construct it with the
same um x value or you can start with
the random x value currently paperback
uh because there's a random one but
it'll be very very trivial to get it to
be able to construct a new one with a
specific x value um and that's it and um
now
the reason why we include the signing
key um uh the private half of the
signing key inside the secret is for
this reason is for this feature um
because otherwise because all the key
shots are signed with the same key
you need to have the signing key as part
of the secret so that when you do this
reconstruction you can then get the
signing key and then use the signing key
to then sign the new key shot without
that any new key shots would be would be
invalid
and actually this is where we get into
the additional features um so as i
mentioned all the documents include both
a document checksum and a signature from
the signing key as well as a copy of the
public key to detect forgeries um and uh
as i mentioned we have this signing key
inside the private half assigning key
inside the secret but there is um sort
of an obvious feature to add which
paperback has which is that you can
actually create a document that is
sealed um now it should be noted that
because of the mathematics it is always
possible to construct uh new shards
that's just how the math works there's
no way of stopping this however because
we have the signing key um you can
create a like a tamper evident i would
call it a document where you can tell
whether or not a new key shard whether a
keyshot that is being used was created
after the initial set and the way you do
that is simply that when you create the
secret that you're sharing rather than
including the um the ed2519 private key
you just include all zeroes and then um
you can't just remove it because then
the size we've got to tell people
whether a
document is sealed or not um but either
way you basically don't include the key
and therefore when you even though you
can expand it mathematically um the
new key the new key shot that you've
created cannot be signed and therefore
it is easily detectable that particular
key shot is not original um
and yeah and also we have we use um
zbase 32 to make it harder to say
characters as i mentioned um i have
looked at using emoji sum to for the
document identifier um but this has a
slight flaw that well now the check sum
no longer is the last eight characters
um and also emojis might
change over time there are lots of
issues with this particular thing but
it'd be nice to have an um a slightly uh
still easily recognizable um but
slightly high high density um
encoding uh for the checksum so that you
can easily tell whether or not the
trickster is whether or not there's a
forgery or the trickster has changed or
whatever
okay so where does paperback stand today
well at the moment this is with the
documents that if you generate the
documents today this is what they look
like um i joined these yesterday uh
you'll see that you know it looks fairly
similar to the sort of mockups that i
have the only thing that's really
missing is sort of minor text styling as
well as um the banners that are listed
um the reason they're missing is sort of
a very boring technical reason um it'll
be fixed soon basically it boils down to
the pdf generation library i use does
not support um text justification um it
doesn't do any sort of text formatting
itself you have to manually format
everything and as a result um generating
banners with the text or centered is a
little bit complicated um and i just
thought it'd be better to just get
something working and i'll add them
later um so that just requires adding a
new library that does text certification
and the calculation for me um but yeah
that's that should be fixed um
relatively soon in fact it's probably
fixed by the time you're watching this
um anyway so uh the current status yeah
is that all the payback operations i
mentioned today are completely
functional um through the command line
um so you can generate pdfs including
your extra pdf so you can generate um
backups with with pdfs and key charts
and all this right you can do a recovery
if you just copy paste the qr code data
or the text based backup data
if you paste it into the command line um
and yes and record and um
uh expansion also works perfectly fine
um the only downside is the current
styling doesn't quite yet match the
mockups perfectly um but that's language
which i'll i'll fix soon um the next
steps or the next things need to be
worked on um are
there a couple uh main ones are larger
documents and um having a nice graphical
interface so larger documents at the
moment we don't compress any of the data
um the reason is that i wasn't entirely
sure whether it would be safe to do so
because of the crime and beast attacks
um which were targeting um compressed
and encrypt um schemes however it seems
to me that those only apply to like
interactive scenarios where you where
the attacker can give can trigger you
into
adding whatever data they want into the
payload um but that's not the case for
paperback payback is like a it's
literally the is the least interactive
thing least interactive thing you can
think of where it's just it's a printed
page so i don't know um
it probably is safe to compress but i'm
not entirely sure um i'd love a
cryptographer to come and tell me um the
other issue right now is that um at the
moment payback will only generate a
single page main document
um the reason for this is a fairly minor
um
it doesn't really it's not a technical
limitation because as i mentioned um
each qr code um stores the index and the
index is using um variants which means
that you can basically go as large as
you like in terms of number of qr codes
and the index of each qr code um the
reason why it's limited to just single
page at the moment is purely because um
i haven't quite figured out what the
styling should look like when you have
more than one page and also practically
speaking it is a little bit complicated
to print um duplex pages where you have
um like you would have to type like one
comma one two comma two three comma
three if you when you're doing the
printing to get the right duplex setup
um yeah the other thing is that i'm not
sure about whether or not if we do end
up having more than one page should we
should be able to handle if someone
loses a page so that means should there
be sort of redundancy where there is
like you know one extra page which is
using like solomon read or something um
as a redundancy page i don't know these
are all open questions i would love
your feedback or opinions on this topic
um yeah the other thing right now in
this sort of much bigger undertaking is
mobile or web-based applications that
you can use for recovery because
ultimately these documents
most likely will need to be recovered by
your family or your heirs or whatever if
you're using it as a backup probably you
will also be able to be recovering at
some point um but it's very important
that this is saying which like an
ordinary person can use um at the moment
it's command line tall completely
useless for like ordering people um so
it'd be nice to have um someone who is a
lot better than me the graphical design
i'm absolutely awful at it um to work on
some sort of graphical interface um the
issue right now is that also you can't
scan the qr codes on desktop um because
i couldn't quite figure out how to get
that work theoretically it should be
possible to just take a pdf or take a
scan of a pdf and then do the qr code
recognition on the scan um and then that
way it could be we could say okay well
this is just a desktop only thing but at
the moment mobile phones are much much
better at um doing qr code recognition
because you can just you can actually
pick where you're scanning
physically um as opposed to like if
you're doing a whole page thing you need
to like find all the qr codes and all
the rest of it um anyway
that's something to work on in the
future um and it'd be i would love some
help with this because yeah i'm i'm
really really bad at um at ui design um
and yeah and also some sort of review in
order to be great um the shimmy secret
sharing code um is written by me so this
is a case of i um i am fairly sure that
it is it is secure i have written a very
large number of unit tests to make sure
that um all of the main properties that
have to be preserved for streaming
secret sharing are preserved um but i
can't guarantee anything um there are
probably places where it's not constant
time whether or not
time matters in this particular case i
don't know but yeah it'd be good to have
some cryptographic review in order to
double check the things are safe and
also the design is is also the same um
then we have sort of open problems
and this is a little bit um harder to
deal with
so the first problem is how do we ensure
that documents that are generated
paperback are actually recoverable
practically in 20 30 50 100 years and um
you know i'm going to use paperback for
my own stuff so that means that you can
be sure that the program will probably
continue to run for at least you know
another 20 30 40 years um as long as
it's something that i need
but that's probably not enough
consolation for most people um so there
needs to be some sort of other backup um
just in case the program's working you
know the website goes down github goes
down everything goes down that you still
be able to recover it at least in theory
um and so the
sort of obvious solution is to have some
sort of um is to somehow have some sort
of textual description of the recovery
algorithm um or to have like a basic
implementation of just the recovery code
um either pseudocode or python or
javascript or some other language which
is likely to be still usable in 50 years
from now um the main downside of the
textual approach is that you would have
to pay a developer to like actually
develop a program that does the thing um
while
if you use pseudocode or whatever then
or the same thing with pseudocode but if
you use like python or javascript or
some other language um it's entirely
possible that you know in 30 years that
the language were completely dead and no
one will know how to use it
so it's a bit of a trade-off probably
the best thing to do would be both but
i'm not entirely sure um and yeah and
the other issue is whether or not we can
assume that qr codes will be honest in
the future now we could explain how qr
codes work in the text description of
the recovery algorithm um but that if we
can't assume they know how to use qr
codes then that means we can't qr encode
the code which means it would have to be
printed like regularly which you know
it's not clear to me that that's going
to be very space efficient and like is
someone really going to have like carry
on like a 20 page tome of how the system
works for 40 years probably not so
ideally just a qr code with like the
most minimal code example we can to get
to work um and i've spoken to some
people some folks believe that you know
in the future at the very least like
archivists will be able to understand qr
codes because they've been using so many
different things um you know i mean
they're used in like how to get to more
but they're using like tombstones so
presumably someone in the future will
understand
um what qr codes are at least at some on
some level
um the other question is whether or not
there are any better density codes we
should use um data matrix or color
barcodes like htc jab codes htc 2d um
these are all the last three are color
bar code systems um and data matrix is
just is a black on my bucket system but
is um uh but has higher data density and
can store more stuff
uh the there are trade-offs between them
data matrix is um i've discovered that
once you get up to large sizes the first
thing is even with qr um you can get
higher density than i'm using here the
900 bytes is not the the most bytes you
can fit into a qr code you can fit up to
i think 3k into a qr code the problem is
is that most qr code scanners can't
handle qr codes that have that much data
in them i discovered them on my phone
usually once you get past like 1k your
phone scanner will no longer let you
scan a code that has that much data on
it um which means practically speaking
1k is the practical limit of like a
regular qr code that you can scan with
an actual phone um and similarly with
data matrix i find that um data matrix
is even more flaky when it comes to
scanning you end up with like oh you can
scan it but it doesn't actually detect
the the code is there um where it starts
scanning bits of it is like a 2d barcode
um yeah as for color barcodes color
barcodes have the have the capacity to
be far much far more um
uh dense
the issue is is that now well now you
would require everyone to use color um
uh color printing which is gonna have
its own issues and also um it's not
clear to me how the color will last over
you know 40 50 years um and that's a
different topic so maybe maybe we should
maybe we shouldn't switch i'd love to
have um the other people's thoughts on
this
so finally a very quick aside about
paper storage um with paperback so as
the name implies paperback is a
paper-based backup system which means
that taking care of the paper that you
use for paperback is quite important um
i firmly believe that paper is arguably
one of the most resilient ways of
storing data but you have to treat it
right so uh the first thing to consider
is sort of the obvious one which is that
you probably want to print everything
double-sided with like full duplex um
where such that if one side gets
slightly damaged the other side will
still be readable um in addition you
want to use archival grade acid-free
paper over regular copy paper regular
copy paper has acid in it which slowly
eats away at the paper and the ink um
which means that over you know 50 years
the pages will become yellowed and also
the ink itself will start to get damaged
um which means which means it might be
impossible to read in 50 years time
which you want to avoid
in addition to that you want to avoid a
hot lamination
um which is sort of what you want to
think of when you think of laminating
something which is that you know with
the hot rollers and you have the sleeve
you put it in that then melts into the
paper um the problem is is that the this
the first of the melting process is
quite irreversible pretty much and so um
you're put like permanently bonding this
to the paper the plastic of the paper
and also the material that's used inside
pouches is um is not entirely inert it's
actually slightly slightly reactive
which means that it is slowly reacting
with the paper meaning that it will
actually cause paper to degrade faster
than it would normally um and in
addition um if there's any oils or
anything inside the on the paper when
you sealed it
those are sealed in with the with the
plastic um
what you should use instead is what's
called encapsulation sleeves basically
they are sleeves that are made of an
inert material where you can put the
paper inside and then you can tape up
one of the ends or you can um you know
thread the end together or whatever you
prefer and that way it is the page is
protected from spills which is the main
reason why you would laminate something
um but but at the same time you can take
it out
and the um sleeve itself is made of
inner material such that it won't react
with the paper itself
um yeah so these are just sort of
general guidelines i'm not an archivist
this is sort of what i um glean from
reading up a little bit about it um
national libraries usually have pretty
good archival advice the australian
national library um used to have some
pretty good information on their website
but since they changed it a couple years
ago i wasn't able to find it if you go
to paperback i have archive links to the
original page uh original pages which um
detail some of this stuff in detail um
in addition to the container the
canadian conservation institute um has
pretty good information they have like
very detailed documents about not just
how did you what like what side of paper
you should use but also how you should
store it what kind of boxes you should
use to store and all the rest of it
probably a little bit too detailed for
like most uses of paperback but it's
something you should at least have in
mind to consider when you're when you're
printing this stuff
and with that uh that's everything so
any questions
okay thank you alexa for that uh
wonderful presentation
uh first of all could you just let the
audience know where they can obtain
those slides and uh any other links
yeah sure so you can get the slides from
cipher.com talks or my github which is
github.com
cipher c-y-p-h-a-r
talks
great now we have a few questions
available in the chat window so first of
all how large can the secret practically
be
yeah so um at the moment because we
don't do any compression um the secret
is limited to about like 8k or 9k um
bytes um the in theory if you did
compression you could
bump it up a little bit more um but as i
mentioned there there are some limits
size limits with qr codes so you also
you are sort of practically limited at
the moment um in the future i do plan to
um have like multi-page support i think
i mentioned that in in the in the last
bit um with that you can make it like as
long as you as big as you like
effectively um there is like a
theoretical limit of like 2 to the 32
because of the um because the field we
use um but like that's more bites than
anyone ever needs in a lifetime
great
and how do you think that where you will
get paperback as a project to a point
where people will trust that paperback
will still be readily available and
usable over the time scale people care
about for digital wills yeah that's a
very good question and it's it's a
problem that sort of stuck with me
because it's not really an obvious
solution um i think that there are a
couple of things that you can that i can
do to make it less
dependent on me specifically um one of
them was as i mentioned you can i can
work on making it so that there is like
a self-contained description of how to
um decrypt the data so that you can go
to anyone who knows how to like use a
computer and knows how to run like a
python program or whatever um can
decrypt it and i think that that would
go a long way um you know there are a
couple of other options um you know like
i don't know maybe there's like internet
archive ways of doing it um yeah i'm
entirely open to discussions about ways
of improving that because i do agree
that it is um
you know if if it wasn't me for someone
else i would also be quite hesitant
about leaving something that i need to
that needs to be used by my heirs in 50
years that seems um pretty dodgy so yeah
um yeah it's a difficult question but i
think that those things can probably
improve it so work in progress
yes
okay and which finite field are you
using in the end
uh yeah so we're using uh gf-232 like
the um gower field two to the 32 um and
the this is a bit technical but the um
the characteristic polynomial is like
sort of like um the most obvious one
it's the smallest when you're observing
binary it's the smallest one um but yeah
it's just um yeah the reason why we use
um gf-32 is because um so two to the 32
um is because um using like a prime
field um
uh as far as i can tell it's difficult
to make a prime field that is actually
um
uh that is efficient like that is it is
well sorry it is efficient um the issue
is that you have to deal with that it's
usually not constant time and also it's
kind of difficult to like easily chunk
up data that way um so yeah we just use
the the gawa to the blah field which is
32 in this case
excellent okay so in the absence of any
other questions
thank you for the presentation and
we'll end the video there
okay thanks for watching