Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/1069 Thanks!
[Music]
so welcome and our next speakers are
Sophia SEL and uran peran and they are
going to tell you about the newest
version of the of the record protocol
version four and as well as encryption
they are going to touch on morality and
ethics and why we encrypt and why we
need uh
communication so please
welcome Sophia and
Ur okay so hello and welcome I am Sophia
and this is Jud and as it was said we're
going to present the version for the OTR
protocol but we also going to we named
this talk no evidence of communication
or morality and protocols for a reason
and you will see during the talk
why so the first thing that came to us
to our mind when we decided to present
the version four of the OTR protocol was
to talk to the audience why we need uh
why why we need secure messaging and for
this we decided to one of the most
famous papers in cryptography that was
done by Philip rway in 2015 which is
called the moral character of
cryptographic work and this paper starts
by saying that most academic
cryptographers seems to think that a
field is a fond deep and political
neutral game a set of puzles involving
communicating parties and notional
adversaries this vision of who we are in
m a field whose work is in
intellectually impressive and rapidly
produced but also quite in breed and
divorc from The Real World Concern is
this what cryptography should be like is
it how we should expand the bulk of our
intellectual Capital the reason why we
wanted to show this quote is basically
that for a start of a talk is to start
inquiring in ourselves if what the work
that we're doing is actually the work
that we should be doing because at the
end of the day we as privacy and
security developers or cryptographers or
software developers we own the product
and the design decisions we do for the
real world people who are the ones who
going to use and if we're going to give
a protocol or an algorithm or
product to them then it should be also
interpreted with ethical and moral
decisions and of course Roa um does a
lot of points in his paper but uh there
an a special paragraph that actually
concerns the main focus of our talk in
which he talks that basically one of the
things that sometimes have been
abandoned by cryptographical security or
privacy research is the problem of the
secure messaging he says that of course
there has been some research and of
course there are some options but there
has not been that much intensive
research and one of the reasons why
presenting today OT in this version four
is because since the beginning OT tried
to solve this problem of secure
messaging and try to give to the user
back a privacy that sometimes big
corporations of government have actually
taken away from
them and of course as I already said
there's a lot a lot of um not a lot but
some um alternatives to the secure
messaging protocols there's a lot of
protocols that try to do that but in
this talk we will also argue what we
need actually a protocol that of like
OTA that actually uh sets uh the bar
around the definitions limitations of
properties that we need when creating a
protocol so one of the thing that of
course if we want to solve the secure
messaging problem because this is a
problem that users actually need to be
solved because one of the things that
real world users do in the internet is
communicate between each other so we
actually need to solve this problem and
one of the things that we need in in
order to solve this problem is to give
to the users uh options that work
sometimes a lot of secure messaging
protocols don't actually give any
implementation for the user to use or
actually good design decisions so they
can actually know what they are using we
also need full specifications it's not
enough to actually do a secure messaging
protocol that is only defined between
three block post or a half a
specification or just an implementation
we actually need protocols that are
highly structured enough and that um say
that that not only say what crypto
cryptographic algorithms are used but
actually Define how these cryptographic
algorithms are used and how they relate
to each other it is not enough to say in
a protocol that you use elliptic curve
cryptography you have to take in account
how eliptic curve cryptography um Works
between each with other algorithms and
how it takes into account different
kinds of attack I don't know may the
phobe with you side Channel attack
co-actor issues ETC Etc so we need full
structure specifications we also need to
define a specific specifically which
properties a protocol is going to try to
solve by saying okay this is try to
solve deniability and all of the types
of deniability or only some types of
datability it tries to solve perfect
forward secrecy or whatever property it
is a protocol should also Define which
limitations it has because a protocol
cannot solve them all um in OA before as
we were going to see in some next slides
for example we didn't try to solve the
postquantum algorithm uh the quantum
Computing problem because obviously
postquantum algorithms and as you can
see if you attended Tanya langes and
Daniel B's talk yesterday you will see
the postquantum algorithms are not good
enough right now to be
deployed we also need protocols that
update existing definitions because a
lot of people sometimes says that we
have already a protocol so why should we
update to another protocol if we already
have one that looks good enough it might
look look good enough today but in the
future or right now already the Academia
has uh actually defined in a proper way
the definitions of the security
properties that your protocol is trying
to attain of course for protocols we
also need review and verifications
because it's not enough to put a
protocol on the internet and expect that
users use it it has to have formal
verifications revision by several
Parties by cryptographers software
developers Etc and verifications we also
need implementations and by
implementations that mean code that can
actually run on several operative system
that can compile and actually run and of
course um most importantly we also need
ideas from different places something
that we are very proud from the version
for of OT is that actually most of the
developers of OT come from Latin America
specifically from Ecuador and Brazil as
sometimes we actually need ideas coming
from different places because it's not
enough to just have ideas from a certain
region of the world and impose them into
another region of the world you will
find that there are very good ideas from
other parts of the war that needs the
attention as
well all
right so now we're going to talk about
um what actually is OTR of the
recompensing and what exactly is
deniability so in the beginning um there
were three people who wrote a paper Ian
Goldberg Nikita borisoff and Eric Brewer
and they created this paper called off
the Record messaging and basically what
they wanted is that they wanted to have
messaging algorithms and and and
protocols in the world that would sort
of mimic conversations you would have
casually like in the real world and
bring that to the digital world right so
what pgp did for example is that you can
sign a message where you can say oh this
message is actually written by me um but
in the real world what you want is
actually say I have a conversation with
Sophie that I know it's Sophie but if we
have a one one conversation somewhere
nobody knows what was actually said and
that's something we wanted to that that
um you know Ian and and the others
wanted to incorporate into um an an
cryptographic protocol and so um uh they
did that um and then it went through
several uh revisions um and one of the
cool things as well is that you can sort
of authenticate somebody right in a
deniable way we'll get more into that
later on um but sometimes you know you
want to sort of verify that the person
who still controls a certain account
like of xmpp or of ISC um you want to
verify that that is still the real
person that you are expecting and that
was done through like the Socialist
millionaire protocol where you can sort
of authenticate somebody uh sorry verify
somebody um and you know OT gave like
inspiration to like a bunch of other
secure methoding protocols uh and signal
was definitely one of them
and so some of the properties that ogr
has is like authentication so there's
like an authenticator key exchange there
is a variant of the sigma protocol which
signs which stands for the sign and Mac
protocol but what was different in the
OTL version is that they sort of remove
the signing part um and it still worked
through the through the Mac stuff
because you can sort of like because
just like what what I said before you
don't always want signatures and and
they uh achieved it this way um and then
through the verification right the
social millionaire protocol you can sort
of like have a shed secret or have like
a question and answer uh where you can
ask a certain question and hopefully
this person only knows the answer to
that question that you
ask um as well as like fingerprint
comparison like out of
band um and then you know it has end to
end encryption so all messages are
encrypted between the two Dev devices
that are talking to each
other and so another important thing is
is like the perfect forward seeny right
so uh there's like unique keys for every
um conversation that you're having and
like every mthod and every like session
that you have and why this is important
is that let's say the device gets
compromised um and somebody gets access
to your phone that at least and the
attacker can't decrypt the messages that
was sent earlier because every
uh session has like a unique key
um and then the post compromise security
right is that even if a message key gets
compromised no future messages can be
decrypted um where if Alice has like a
security guarantee about communication
with Bob even if Bob Secrets have
already been compromised um you know
they can't really do anything with
that and so we get to the the liability
part um so so the liability in like the
OT version three which is like the the
sort of like previous version of OTA is
that um you
know considering scenario where Bob
accuses Alis of sending a specific
message Jus in adjust must decide
whether or not he believes that Alis
actually did so and if Bob can provide
evidence that Alis sent that message to
this a valid cryptographic signature of
the message and the L is long-term key
then we say that the action is run
reputable otherwise the action is
deniable um and so with the sort of
change in the Oto version 4 um the
theability part is that um it has sort
of like the theability has expanded so
let's start with the two easy ones one
of them is the message so if you're
sending a a message you can sort of like
deny that you have standard message but
you can also deny that you actually are
participating or had participated in
that message in that conversation with
somebody and then the offline one is
that let's say we had a conversation and
we ended the conversation we can you
know Force the transcript afterwards and
online is is that somebody might try to
collude with the network somehow to try
and figure out like what's going on and
also that party cannot um verify you
actually having that conversation um of
course you know cryptographic Protocols
are never a silver bullet so you
shouldn't just rely on deniability for
like uh you know your perfect
operational
security um and a protocol is strongly
deniable transfer provide no evidence
even if long-term key materials
compromised and now Outsider can obtain
evidence even if an Insider
interactively colludes with them which
is the online
deniability okay so basically what we
Tred T in the forward version of OT that
we wanted to have all of the properties
that OT had plus all of the academic
definitions that have already been
updated we wanted to have forward
secrecy post compromise secrecy but also
online deniability offline deniability
deniability participation deniability
and message deniability one of the
reasons why in the past OTR did not
Define all of these inabilities was
because in the Academia there was big
terms around what online deniability was
and offline deniability one was but what
we wanted with the version four is to
update this protocol to catch up with
what the Academia Academia has already
defined so we can put that onto a
protocol that can be used by the real
war people and as you see here we have
puted a table of compa between the most
popular secure messaging protocols um
OTA has most of the poor properties um
of course and some cases we don't have
the full property you only partially
provide the property and this is
something that we also wanted to make
very clear with OTR to say the
limitations that the protocol has not
only try to say to the user oh this has
it all it actually has some limitations
um some of the properties and the
mapping that we have made of other
secure messaging protocols might not be
that accurate enough because we have
based our research on the protocols of
these secure messaging protocols uh or
the blog post that some they have and
sometimes these block post are not
updated enough so yeah be aware
okay so what we have Aion for OFA of
course as we already said we wanted an
ability we wanted an ability all of its
form as UD has already pointed out we
wanted participation message online and
offline durability we also wanted to
give a strong perf forward secrecy and
post compromise secrecy we also wanted
to update the highest security level and
this is related to the next point which
is that we also wanted to update The
cryptographic Primitives why is this is
important in the secure messaging
protocol is because most of the times
you have algorithms and you think okay
this algorithm is good enough but then
of course someone finds an attack
against this algorithm or an issue of
the implementation of that algorithm so
we should also update The cryptographic
Primitives to something that has enough
Crypt analysis and is good enough to use
um we also wanted to Pro to provide
additional protection against transcript
decryption in the case of EC compromise
we wanted to use elliptic curves this is
a very important point because one of
the things as I already said in the past
is that we don't provide Quantum
resistance in OT before and one of the
reasons is because as I said uh there's
still no Quantum algorithms that are
good enough to be used right now in a
massive way um we will wait until the N
compe competition is over to maybe
reconsider this thought but the N
competition is still ongoing so we will
still have to wait on that but in the
case that Quantum machines come earlier
as we thought then at least we will use
use a Dy Helman of a very large Prime so
it will be more difficult to break this
very large Prime Dy Helman that the
litic curve cryptography but of course
we also wanted to use cipic curves
because cipic curves have a smaller
Prime but um they have the same security
level a bigger security
level we also wanted to incorporate a
new communication model that now we have
when OT was first developed we uh it
only supported synchronous online
conversation and right now we all also
need online and offline conversations so
that is something that OT before also
provides we also provid in order and out
of order delivery of messages we also
give the implementers several ways in
which OT before can be implemented
because sometimes implementers only want
to implement the online version of it
and of course we also don't want to
trust servers because servers can be
tricky to manage um we don't want to
trust them and that's the way that we
use the the naval authenticated key
exchange which is a mechan mechanism by
which you authenticate the other party
in a deniable way and you also generate
a shared secret that mechanism uh for
the offline mode needs a untrusted
server that is going to cash for
sometime ephemeral
material here you have the main changes
if you go to our repository and our
protocol you will find it but just to
show okay um some design decisions um of
course uh instead of something simpler
as people has has put it um we use de
set and xcdh which are two Dees as I
defined de is a denal authenticated key
exchange um and we wanted to have these
two de because these are the ones that
mostly give the datability properties
that we need we also wanted to use the
lip curve e44a goldilux by Mike hurg
because it give us the security level
that you we wanted to attain of course
as I already said because we wanted to
make sure that quantum computers might
take some time to decp some parts of
what before we also wanted to use a d
Helma uh
372 we wanted to use shake and xala 20
Shake is the hash function that we use
in OTA before xasa 20 is the encryption
algorithm that we use the reason why we
wanted to use them is to update The
cryptographic Primitives of course we
wanted to use the double ratchet
algorithm because it's the algorithm
that will give us perfect forward
secrecy by the means of always
encrypting one message with one unique
key and some of the questions that
people sometimes have posted to us what
is the toolkit the toolkit is um
something that otab before always
provides is basically a way to prove to
the people that look into OTF that
actually this gives the datability
properties that it claims to have um I
have already said that we don't suppose
Quantum algorithms and the reasons for
that and of course we also don't have
group chat the reason why don't we don't
have group chat is because there has not
been a good mapping of which inability
properties and security privacy
properties we need for group chat and
there is not a way of to create a very
strong strongly denable um Communication
in a group
chat okay
well uh of course as I said at the
beginning one of the things that we
should also have when we design a
protocol is that it should also have a
good implementation an implementation
that runs in most of the operative
system and implementation that compiles
and implementation that runs and for
this we wanted to have a real world
implementation
right so we did that through
collaborating with uh two different
entities M mainly the cryptographers who
worked on like um the deniable key
exchain um at the University of woo and
the developers who you know have
implemented cryptographic Primitives but
also like working on like the actual
like code of the specification that is
OT version 4 um so uh that came out you
know Lip lip Goldilocks is an
extension of lip Decap from Mike Hamburg
uh where we uh said well we only are
going to use Ed 448 for like a specific
encoding um there's going to be um know
people at the moment working on
different implementations and why that
is important is that you know we want to
be able to also like test it out and see
where there's any uh flaws maybe in the
specifications or things that are
unclear and so far that has helped us to
um clarify soon parts of the
specification um and improve those
parts um and you know we've been
collaborating with the cryptographers
while they were wening the papers um and
a lot of the revisions of this uh work
have been reviewed by Ian Goldberg and
Nick anger um who have worked on like
the deniable key exchange uh paper as
well as like uh o in
general yeah related to the point It's
always important when designing a
protocol that if you're using a paper it
would be good to always um refer to the
authors so have collaborations with the
authors so you are sure that you're
implementing the cryptographic algorithm
that is defined on the paper in a good
way and actually this is the paper we
are based upon mainly our decks are
based upon the first paper by narang Ian
Goldberg that's the 8448 gold Delux by
my Hamburg and of course we have already
been quoted in other papers like in this
paper from the alto
University
yeah um of course if we wanted to do a
real world implementation we needed to
choose a programming language in which
we were going to implement this and we
choose to do an implementation in C as
UD has already said there's already some
ongoing efforts of actually implementing
in Python Java andolan but the main
library has been written in C what we
wanted see well C is always the library
that c is always the programming
language that is often used as a
reference and most of the libraries that
we use were written in C in C so we want
wanted to use the same programming
language but of course when you use C
you will have some problems with memory
handling um I don't know if you attended
uh previously a talk called memsat in
which actually uh the talker explains
some of the problems in memory handling
but we had to um to verify this memory
handling in our library in a good way
because if we're going to provide a
library that is going to be used by the
real people then it has to not have the
memory problems that some libraries has
for that we Tred to we incorporate a
static testing by using clant ID and
splint uh we also use BGR to check
buffer overflows double freeze uh usage
with uh after a free etc etc and various
a
sanitizers uh of course we also wanted
to have um testing in our library in the
form of unit and integration this is
something that is always so uh very
needed in libraries because um sometimes
people um push in production some
libraries that don't actually verify
correctly all of the edge cases that a
library can have in its development
process and we wanted to make sure that
everything was uh okay and something
that actually on the talk of yesterday
by T Langer and Daniel B said is that we
also should put on the cryptographic
things or design or when designing
algorithms we should also make an strip
for code that can be readable because
sometimes your library is going to be
used by other software developers and so
so other software developers should be
able to understand how uh how the
library is actually working so we wanted
code that we that can be used by other
developers we also wanted to give
recommendations to developers because
yes it's it's true that we created this
protocol and we created the design of
this protocol but not because of that we
just should push the protocol out of
there and just say try to implement it
in any way but actually try to keep in
touch with the community give
recommendations clarify things that may
not be good enough enough in the
protocol this actually makes the
protocol M much more robust um because
we catch up some errors that maybe
cryptographers didn't catch up security
privacy experts didn't catch up but
software developers implementing the
protocol did catch
up all right and just like Sophie said U
we've been doing testing but we also
think it's important to actually test on
like various architectures and operating
systems so uh we actually found like a
couple bucks while we were running the
test on like uh some of the um online
like test suits um mainly being like
different GCC and clang versions on like
different um uh uh operating systems and
and distributions from Linux and that
actually like caught some problems every
now and again um we also want to you
know get better support and like the
various bsds that are out there and so
we started working on like um you know
uh continuous integration for those
platforms um and one also one one sort
of funny thing is that um Demian you
know has like various architectures um
and they also have like sort of like
Unix like systems so we managed to like
find some problems like the the G herd
uh is out there and some other U more
exotic like architectures on like myips
and power PC um and it actually helps to
sort of like have like a wide range of
of uh architectures that we check for
any
mistakes yeah and something that is also
very important when doing our
cryptography protocol that real world
people are going to use is that we
should always prioritize the real world
people that is going to use it because
at the end of the day the use some Ms if
you're pushing someone something to the
world then of course some user is going
to use it so we try also to at least
when we did uh our implementation of the
plugin to the pitching client to at
least make the dialos dialogos dialogos
more understandable on how they actually
try to attain like for example if if the
process of generating a private key then
it should be clear enough to the user
what that process that that process is
happening and of course something that
as we said is also needed when you are
designing a protocol and something that
we tried to include on OT before is
actually doing formal verifications of
all the protocol so we tried so right
now there's an ongoing worker actually
doing a model Checker of the protocol
estate machine that is going to be done
in the tool C Murphy and eventually we
want a full protocol for formal
verification this is important because
as I said this is one of the reasons why
you should have a full structured
protocol because sometimes between the
interaction of one state to other state
is when errors and mistakes occur so you
actually need to formally check all of
these steps to catch up maybe issues or
mistakes or potential buxs that can
happen in a
protocol right and we also really care a
lot about
security so especially in cryptographic
protocols we actually want to be sure
that the code that people are using is
like reasonably secure so we want to
sort of like start working towards
fuzzing so we want to integrate Parts
like lip fuzzer and using like stuff
like AFL and hopefully we can run that
on like the the OSS F which is an
initiative by Google where they provide
uh app engine um computational time in
order to run like fuzzing tests
um and we also really welcome Community
audits so um there's like a security pgb
key on like security
at. um so if you ever want to email
about any flaws that you find please use
something like this or email the A4
people um on the the the autonomia
digital email address um and we you know
we don't uh only stop there we also
actually want to get an A Professional
Security it uh by the code that we've
been uh
coding okay so just to have conclusion
what we wanted to attain with OT before
is to design a very structure protocol
specification that actually say how the
interaction between different
cryptographic algorithms work to check
that everything is correct we wanted to
also give to the users a real world
Implement a real world specification
that actually is a structure enough says
what limitations this protocol has says
which design decis it has says which
requirements it needs because that's
sometimes something that the users and
implementers actually may need because
the user may choose between different
protocols depending on how the
specification is defined we also wanted
to give this real world implementation
that didn't only care about implementing
it just in whatever way in whatever
programming languages but actually to
make sure that this is implementation
that is production ready that can be
used by people and that can be used to
base other implementations upon that
that coming again with what we started
at the beginning with the Philip rways
paper basically that's what we try to do
in OTA that this is a protocol that
tries to solve the problem of theability
as a basic right of people when they
having a communication in the digital
world and also as something that takes
into account this morality and takes
into account the requirements and needs
of the uses when they actually need
something that is specified good enough
that is implemented good enough for them
yeah and check out our repos uh they are
in J have this is the protocols we also
have the library in see the priy server
um the toolkit uh our implementation
half implementation which is not done in
Golan the implementation in Java that
was done done by Danny is been is going
by Danny van
hman and yeah and check out also our
website and we also wanted to thank
everybody okay you yeah um so also just
to like add like a little thing so we
have like an sort of Oto Community
website called od. IM which also has a
gith a giab instance and we have like
various like continuous integration
possibilities so if you ever want to
move from ghub for example or git lab um
we are like happy to host you um on this
platform um and provide uh um continuous
integration capabilities for
you okay we also wanted to thank
everyone involved otab before has been a
protocol that has been done by a lot of
people from all over I think from almost
all of the continents in the world um we
wanted here to show up the people who
have more than 6,000 lines of
collaboration or code of text in a
repository but there's much more if you
can you want to know who have who has
collaborated you can also you can always
check a
repositories here's some time for
reference if you want to know the papers
we based upon this talk and
yeah
questions
[Music]
yeah thank you and of course thank
everyone involved for the amazing work
on OTR and thank you for the great
presentation we have time for questions
so line up in front of the microphones
we have five of them um in the front and
in the back of the
hall
we're going to take a question from the
internet
first um the question is are you in
touch with developers of popular
messaging applications such as signal
and if yes um will the protocol also
support uh media other than text such as
VIP or video or something okay um
attached I don't know but yeah we have
um we have not collaborated with them uh
specifically we just have collaborated
with um the people who in the past did
OTR because they are the ones who also
did right now the newest papers and the
reason why we wanted only to update OT
is because OT has always been the
inspiration to other protocols the Signa
protocol based itself on OT um so we
wanted to first update OA only in the
past uh tror perin when we first pushed
the first draft of the OTA he suggested
us that we should also publish the first
drop on the mailing list that that mod
than curves have um but we have not
closely collaborated with them now
around the second question which is
around video and audio you can always
support them uh in know if you want
encryption of video or attachments uh
you can always use the thing that's
called the extra symmetric key for those
purposes yeah so it was actually already
implemented in the version 3 so um
except no actual implementation
happen
thank you uh microphone number one well
my question is related to the capability
of omo to support multiple devices which
is very important in the modern world
and I wanted to know if OT V4 can do
this and still provideed stronger say
deniability guarantees thanks so much
for your question this actually moves us
to
this
congratulations
yeah okay
um this this is a common question that
we have and past part of the question I
think it's also important to answer this
so right now otab before and since ot3
OTA has a thing called instant sax that
is the ones that actually um identify
several devices so when you send a
message you will only be identified to
that specific device device does not
multi synchronization of devices because
that will create some privacy concerns
um so that's not there like multi
synchronization between devices does not
there but of course um you can use
several devices and if the devices
recognizes which instant tack instance
stack that belongs to it will always
send to the correct device um if you
want difference with amimo is that of
course uh Otti before and oti is more
agnostic uh and by it means that OT can
be built upon any other messaging
protocol that there exist not only xmpp
if you want to build OTA over IRC you
can do so and even today because we
supported offline messages you can also
build it if you want us an email and of
course OT has Better theability
Properties I have not seen any paper
that actually said theability properties
in the concern of multi synon
synchronization devices maybe that's
something interesting to look upon
and of course4 has a little bit of much
more well defined
specification thank you as a reward for
unlocking the secret slides we're going
to have a question from microphone one
again um yeah apologies this might
actually be out of scope but one of the
problems with messaging apps like on
your phone is not just the encrypted
chat session but discovering people and
matching people to initiate first their
first Contact do you have thoughts on
how that might you know on how that
problem gets addressed
yeah okay that's the contact Discovery
problem right um so basically that is
much more in the sense of something that
is Deployable in a mobile devices um and
of a client and right now right now
we're at the stage of doing the protocol
and doing the basic Library so if
someday we start working into a client
that is going to be supported by mobiles
then of course we will have to tackle
that problem but right now in OT we have
not tackled that because it's not part
of the main protocol it might be an
extension for clients that want to
develop that on the mobile
environments I think it also depends on
like what kind of like messaging
protocol you use underneath right like
this will be sort of tough for like ISC
but like maybe xmpp also is not really
the problem but then if you get into
like the sort of mobile landscape and
everything changes and it's like more
complicated um which is something
yeah thank you microphone three
please um could you elaborate a bit more
about why group chat isn't possible and
do you think it will be possible in the
future because I think it would be
really important for daily
usage yes so um there has been some
efforts in the past as we know there was
at least one
F some years ago about doing MP OTR and
right now there's even a very nice paper
that is called um where is this ah here
um yes this last paper uh secure
messaging is the one that actually
defines like all of the properties that
some um secure messaging protocol has to
have in order to also support group chat
and the thing is that there's right now
not a good uh way of achieving the same
datability properties that you want um
with the current current cryptographic
algorithms that we have now about the
future that actually looks very bright I
remember that we attended pets 2018 and
Nicholas Hopper already presented a
paper around group chat and theability
which was interesting it didn't cover up
all of the secure properties that you
need for group chat but it was very
interesting and during that same uh
conference nicker also um told us that
he's preparing a paper around good
inability in the sense of group chat so
that is something that maybe happening
in the
future thank you one more question from
the
internet could you explain how OT before
forward secrecy is stronger than signals
uh referring to the protocol comparison
slide
Yeah so basically um this depends on the
kind of a of day that you use signal
uses right now one day that is called
x3d uh extended trifle Dy Helman that is
the one that provide that gives this
weak forward secrecy um the double
ratchet algorithm of course gives
perfect forward secrecy but the start of
the de with the with the double ratet
algorithm is the problem how you will
Define weak forward secrecy is that only
it will only protect the deck will only
protect the session key when when both
parties complete the de exchange and in
knowa before we wanted to give perfect
forward secrecy since the start of the
day meaning that it will provide a
strong forward secrecy even if one party
only finished the DAT in Signal you have
to wait for both parties to actually
finish and complete the DAT exchange to
to have the forward secrecy but in OT
before we wanted to have that in a
strong
way thank
you question from microphone
one H in the links there was a mention
of a a priy server is that a server side
requirement like signal
those so is that a what a prey server
yeah yeah the links it's the same as
signal you're asking yeah I think signal
has some requirement in the server side
is that a requirement for
otr2 Signal defines also an unrusted
server I don't know that much in a
requirement from an implementation
standpoint but our requirement from OT
before is also that's in a trusted
pricky server mean meaning that we take
all of the precautions that is needed
when you're using an unrusted pry server
we Define the limitations because you
can have a lot of deniable of service
attacks like someone can drag all of the
the femal material that you have on the
pricky server someone
can can make um yeah someone can publish
the something else so we wanted to have
all of the security um considerations
when using unrusted pry SE like for
example the submissions that we do to
the pricky server are always
authenticated also in a deniable way
with the server um we don't use a signal
because signals in the case that for
example you run out of Emeral Keys
signal will use a static one uh per
default in those cases we didn't want it
to use that because that actually can go
against on theability properties so we
in the case that there's no more Emeral
material in the pricky server we just
wait until someone publishes more to the
pricky
server thank
you what it's not required except yeah
and of course and a trusted pry server
yeah thank you is not required unless
you want to support offline messages
some protocols may only want to
implement the online version of OTR
because I don't know those are their
requirements only if you need to use
offline uh as synchronous communication
is that you will have a pricky sub
thanks uh one last question from
microphone
one I wanted to know if you um worked a
bit in the between the integration of
rv4 and the other protocol actually one
of the strengths of a memo is that it's
perfectly well defined with how the key
where the key are store in xmpp uh
between the account and how they are
exchange and then it gives you a really
nice and well defined way of where to
find the keys in uh in xmpp while on OTR
you always have this like pre little tag
on the body of the messages which is a
bit ugly and like so I would wanted to
know if you add some thought about and
or if you do some work for trv4
regarding the integration of before and
the other
protocol right so um you know slightly
easier for omo in some way because it's
uh it works only over
xmpp um and with the ot4 protocol we can
sort of like uh Federate over you know
what kind of well I mean not Federate
but um get it to work over any messaging
uh protocol now of course if you would
do something like a prey server over
ISC that might get tricky in some way um
so that might not entirely be possible
um so I think it sort of depends on what
kind of messaging protocols underneath
and sort of try and figure out how we
can Implement these things and maybe we
should sort of move to messaging
protocols that sort of takes these
things into consideration right to have
a sort of Extinction that we can build
upon uh where we can actually plug like
prek key servers into it um it's sort of
like the the reasoning I would use I
don't know if you have so one of the
properties of course of oti is that it
should be agnostic to any protocol that
it's it will buil upon so specifically
defining the xmpp properties or the xmpp
things that we need for OT will not be
part of OT but maybe from a separate
document in which we can give
recommendations for implementers upon
building upon xmpp on the actual
implementation we haven't found that
much trouble the only trouble in the
xmpp thing implementation that we found
out is that we actually needed to uh
discover the priy server and when we
were using the P um Library there was
not an exposed Heather for actually
doing that so we had to do some tricks
to actually do that thank you that was
the last question thank you for the
amazing talk thank you for your work
thank
[Music]
you