hello and welcome to encryption for
developers or everything that you want
to know about crypto but we're afraid to
ask
my name is james mckee i do developer
security at trimble
um i have some certs in the development
space i have some certs in the
security space which puts me as a pretty
interesting uh place
uh if you want to find me on the
internet you can do so at punk coder
and you can also reach me at punkcoder
protonmail.com
i'm also one of the people behind
besides boulder so you should probably
check that out too if you like this
uh what i do um so for years i was a
developer
and it was kind of over the time of
doing my development work that i ended
transitioning
into uh cyber security
and now i act as a an intermediary
really between the cyber security staff
and development staff
that puts me clearly in the orange team
space
i do things like code reviews and i
teach developers
how to do the things that our
adversaries will do to our software
so that they can learn not to do those
things uh it's a fantastic job i love
what i do
um but much of this talk kind of comes
through that lens
and hopefully that information should be
helpful to you uh
regardless of whether you're following
this from kind of a corporate standpoint
or an individual developer and talking
about encryption
um if by some chance i say crypto i
actually mean cryptography
not cryptocurrency i have a tendency to
to say that
um so let's start with story time once
upon a time i was working in this role
and i was invited to a code review
and the developer was giving me the
opportunity to
take a look at some source code and they
wanted me to
kind of review the the piece that they'd
done but this was done by a junior
developer and basically it was
writing another login page nobody wants
to write another login page so they give
it to the
to the new guy and so he goes through
and builds this
and he was given the device the guidance
that developers should salt and hash
their passwords
okay so what we ended up with was this
code
in which they actually took some pretty
solid
randomly generated cryptographic salt
hard-coded it into the code
and then took that appended the that to
the password
ran it through a single round of sha-1
and then save that off to the database
now luckily we caught this before it
ever went to a production environment
but it kind of speaks to a disconnect
here right
the developer in the space did exactly
what they were told
they just didn't understand the why
but let's stop and step back for a
second ask how did we get here
um you know developers should care about
cryptography this is one of those things
that
you know if we go into the realm of
things that can make applications safe
and make them secure cryptography is one
of those pieces
and many of the failures in cyber
security uh
really come from ignorance about
cryptography and the correct ways to use
it in the correct applications
improperly using cryptography can leave
you in a spot that's
as bad or maybe worse than no crypto at
all
the information that gets to developers
about cryptography and generally about
cyber security issues can sometimes be
translated through four or five
different people before it actually gets
to them
and so you have instances where people
are living off of kind of tribal
knowledge
if they don't know how to handle a
certain piece
almost certainly one of the first stops
is to go and copy and paste something
from stack overflow
stack overflow as it turns out is pretty
bad at giving security advice
especially around cryptography um
but even if they do manage to find that
right place say they don't end up on
stack overflow they end up on
crypto.stack exchange
the internet is filled with information
that can quickly
devolve into really complicated math and
very complicated subjects
that are not directly applicable and
frankly may just be overwhelming to
people that they're trying to get
information across to
add to this development teams have it
rough any developers are not classically
trained in computers what i mean by that
is these are people who went
and if they had any uh post-secondary
education they're studying
you know english or teaching or
nursing or some of these and they end up
in the
software development field through boot
camps and things like that
um management kind of expects developers
to know all this stuff right out of the
gate without training because
um if we take time to go train our
developers
then there's features that aren't
getting shipped
ultimately in some of the worst cases we
have groups that are constant questions
constantly questioned about every step
that they make this seems to happen a
lot more in
organizations where there isn't a
technical mind
at the heart of the development process
kind of the
the project manager doesn't have a
technical background
and what ends up happening is you end up
forcing people into this
uh mentality where they if they have to
justify everything all the time
um that doesn't leave any room for
saying you know what i don't know that
and so it leads to this mentality of
being confidently incorrect
and the second part of this is is
because we don't all kind of come from
the same background because we don't all
come
from the same training space the
language that we speak isn't a common
language
and that's kind of one of the themes
that comes through this talk is the fact
that
in a lot of these cases as we're going
through and talking about it
the language that we use isn't
necessarily the same one
that's used by the development teams
that's used by the people in security
okay so what is cryptography let's start
from the very basics
uh and my the best definition that i
like is
the art of using mathematics to keep
secrets secret
um and really that that kind of plays at
the space we are without going too
deeply into it right
but every once while you get a
development team that says we're fine
our secrets are encrypted
we have to understand the why here and
this goes back to speaking about
the the kind of subtext here right um
if the group that you're talking to
doesn't understand what
encrypted means to them it may mean that
it's just unreadable
then you'd have to go into the
deeper parts to help them understand
that and as part of that we're going to
understand the why behind it we're going
to understand when we use a coding
when we use hashing and when we use
encryption okay
so encoding is this space where we're
really going through and
talking about representing one set of
data as another set of data
and so you know in most cases we'll use
things like base64
encoding where if we pass special
characters
it may cause something to blow up as
part of the process it only can handle
certain characters
and so because of that we have to move
it to a format where it can be passed
through
safely and then d pull decoded on the
other side right
so that's when we use encoding the key
piece that we want to know here is
there's no secret here
we're just transferring data from one
type to another
okay hashing functions now hashing
functions are really interesting space
whenever we talk about
cryptography the key here is that we're
taking an arbitrary amount of data and
we're producing a fixed amount of data
based off of that and ideally it should
be done in such a way that we ensure
that there's always a
consistent value that comes out the
other side
and that we can't determine what uh
what data started with the process in
order for us to go back to that
so if we take a look at the hashing
examples here we've got the lorem ipsum
text
and whenever we run that through we get
a hash down here and we can see that
down here at the bottom of the first
column we've got a set value
now if we were to just slightly tweak
that and change that
uppercase l to a lowercase l we get a
completely different hash that comes out
the other side of that hashing function
and that's one of the real values that
we have in this
is that it quickly lets us tell if we
have
information that's the same on one side
as it is on the other ensuring that we
have that integrity across our data
but there's an additional piece to this
whenever we talk about hashes if we just
have the hash
generally speaking we don't know what
created that hash there's no way for us
to reverse it and so because of that we
refer to this as a one-way function
we can only get data out of it one way
now if we don't take
proper precautions you may be able to go
and take that hash
copy it over to google and figure out
what produced it
but encryption is a different beast
altogether and that's really the piece
that we want to talk about this
encryption fundamentally is taking some
form of
clear text running it through a function
with a key that
is held secret from the process and out
what is produced on the other side is
encrypted
in is you know changed in such a way
that it can't be read
so there's no way for us to get that
information back and it's beyond the
encoding
because if you don't have that key if
you don't have that fried chicken resa
um you're never going to get that
message back it's always going to be
junk
okay so password storage
you know is one of those topics that we
have to to talk about this
because it's the first real place that
most people encounter
encryption and encryption as part of the
process
um and i love this question so whenever
i tell a group that you know we go
through this process and they say okay
how are we supposed to encrypt our
passwords
well the answer is you don't uh we use
key derivation functions
this isn't fully cryptography but it's
one of those
pieces that if we don't talk about it up
front you can easily lose
everything uh before we actually get
into worrying about cryptography
yeah the goal of this is to
slow down or stop the leak of passwords
in the event of an incident
so if somebody gets our password
database we want to make sure that it
takes them the maximum amount of time to
try and guess
all those passwords so they can come
back and use them
in other places maybe people's banks or
various pieces like that
so to do this we use safe key derivation
functions
um for these pieces you'll notice that i
have some benchmarks to get
kind of give you an idea of what it
looks like as we're going through and
generating the initial hashes uh so that
you understand the values
this isn't done on some like super
powerful machine this is done on a mid
core
consumer grade i7 with a nvidia geforce
uh
1060 nothing big here nothing surprising
maybe a little bit extra ram
okay so the first one we're going to
talk about is the password-based key
derivation function too
and really what this thing does is it we
take
a password and some salt and we give it
a
complexity number and this complexity
number allows us to go up and down
and kind of view uh how
many iterations that we want this to go
through to help secure that process
because the goal is if we're only doing
this and we know the right password for
testing
this process should go really quickly
but for each
guess that an attacker has to make it's
going to slow their process down
and so that's really the goal of these
functions um and so for this one we've
got password-based key derivation
function it's definitely starting to
show its age
um but it still can still be very very
uh well set and secured assuming that
you know
use enough iterations as we go across
this we can see even on kind of this
mid-range
uh machine we're still talking you know
milliseconds
of performance to produce these hashes
and check them
yeah so the next one we'll take a look
is bcrypt and bcrypt is really based off
of blowfish uh blowfish is an encryption
we'll
talk about whenever we get into the uh
symmetra key section of this
um but really this has a very similar
process to what we saw with
password-based key derivation function
two um in the fact that it
takes salt a password and we get to
supply the cost
and the cost in this case is measured as
an exponent of two to the
x where x is the cost um generally
speaking
12 is about uh 4096 iterations
um that's kind of the good space we want
to go we if we go
under too for many iterations it'll
start to explode and gets really
kind of um easy to break
so the next one we're going to talk
about is s-crypt
s-crypt is a password derivation
function based on cpu and memory load
and where we see the real transition
here is instead of
kind of forcing a processor to do it
over and over again
we're now scaling out to the resources
of the device that will be calculating
this hash and locking it into that place
um so
you know if this is done on a server
with several thousand cores and lots and
lots of memory
um that's not as much of a problem as if
it's somebody trying to crack these
passwords on a graphics card for example
where the cost of graphics ram is
significantly higher
um and so we have this key derivation
function we pass it
salt and our password uh generally
speaking the block size is always going
to be
fairly standard so generally speaking we
use uh
eight here to produce a decent sized
block
uh the parallelization factor is usually
set up in such a way that it's
the number of cores that you want to
dedicate towards
actually doing the hashing times two
the output key length is another one of
those control pieces that we can put
into place here but we again have this
parameter for
cost and this is going to allow us to
section off a certain portion of ram
now the interesting thing about s crypt
if you look at this the actual
processing time associated with
generating script is very low
okay we have some outliers in here but
for the most part it's it's a very low
process
um so much so because
of the fact that we're locking this to
resources it doesn't have to do
something over and over again
it has the ability to rely on the
resources to keep it safe
but we now move into kind of the the
top level of this and really argon 2 id
if you're designing a new system this is
the direction you should be going in
um it locks the key derivation process
to memory execution time
and parallelization okay so we specify
all of those pieces in there we've got
our parallelism number threads
uh hashing cpus times two
our tag length which is what we want to
come out the memory cost that's
associated with it
the number of iterations and this can
have a significant
impact on the amount of time that it
takes them to calculate as we'll see now
to take a look at these from a breaking
standpoint remember the key is to
you know slow down the process of trying
to break these passwords as quick
as much as possible so if we run sha-1
with salt which is what we saw in our
developers example
we're pulling out 3 800
milli mega hashes per second and that is
a mind-boggling just
pass you can very quickly iterate
through an entire word list
to find collisions in there very quickly
even if we were to just upgrade that
from sha-1 to shot 256
not what i would recommend at all but
it's one of the first things that
developers especially
ones that don't realize what we're
talking about we'll pick out of that
sample
you still reduce it down by a third or
down to a third
now if we move this over to something
like the scheme that's used with mac os
where it's password-based key derivation
function
at you know 1023 iterations
we drop from mega hashes to kila hashes
if we switch that over to blowfish with
something as little as 32
we're now in the thousands of hashes
if we move that over to s crypt with
some decent settings
we get down to the hundreds of hashes
and finally if we pull in and use argon
to id
currently there is no uh no code for
actually doing
a graphics card based acceleration of
this and so you are cpu locked in trying
to crack argon 2 id passwords
and so beca password hashes and because
of that we're down to
on my hardware uh effectively 100 and
maybe 20 hashes per second
okay so now that we have a deep
understanding of how to protect the
first entry into our application we can
move on so
how do we enforce integrity um well
you know all of our stuff already uses
md5 that's secure right why would we
want to change anything we've got years
of of hashes built up
so that we know that things are safe
right well
why do we do hashing the the first goal
is to
to make sure that something is unique to
again go back to that example of the
lorem ipsum
right we're going to pull something out
so that we make sure that the value
is the same whenever we transfer from
one place to another
using that check is really to make sure
that data was not manipulated during
that process
and if somebody can manipulate that data
we've got problems
additionally we want to ensure that it
can only go one way we can't determine
what the original content from the hash
was
and so we get into talking about these
and i'm not going to drain this slide
but the key one that you
really have to call out here is md5 is
really at this point fully broken
there's been some uh stuff where people
could actually manufacture collisions in
that
um and so that's that's genuinely a bad
thing uh
sha-1 has been weak for many many years
we've seen collisions in it and so
because of that it's good idea to
abandon it
but any of the other ones that are on
this list are solid you can use them and
they work for what they need them to
okay
so now that we understand how we enforce
integrity through hashing
let's move over to symmetric encryption
now the interesting thing about
about symmetric encryption is we have a
pre-shared key
and that is the consistent piece across
all symmetric encryption is that there
is a
pre-shared key and so that goes back to
our
our piece where we're saying hey you
know we have secrets right if i have
you know i'm sharing information between
servers
and i have to have that password on
every server then any of those servers
that get
attacked and have that key stolen are
now
able to leak all the other information
on all the other servers
this can be bad so whenever we talk
about using symmetric encryption you
want to make sure that you're only using
it in a situation where you don't have
to share that key
okay or that you're sharing it in a way
that we can handle responsibly
talk about that here in a little bit the
key to this is whenever we do that
encryption process we have text
key produces ciphertext decryption
produces takes ciphertext key
and produces the original text back
now all of this kind of relies on the
ability to use something known as an
initialization vector
and we use an initialization vector to
i'm
sure that any time that we push data
through the encryption
we always get out data that looks
slightly different
because for example if we were to go
through the process and encrypt the same
information over and over again
and say you know okay okay okay
and somebody were to come and see all of
those messages they would be able to at
least determine
that those are all the same and so we're
giving away some piece of knowledge as
part of that
um and the goal of encryption is to not
give away any knowledge it's to keep
secrets
so to do this we have pieces that are
built in so that it gives us some
variation
in how the information is generated from
the beginning
to generate that random information we
use an initialization vector
now for debugging purposes most of the
application
frameworks have an initialization vector
that includes initialization none which
means that initialization vector
includes
all zeros under no circumstances should
you ever use that in a production
instance in fact i would suggest that
you don't even use it in a development
instance
um the goal here is to really make sure
that we go through this process
and make sure that we get out random
data every single time
okay so that brings us to the next piece
which is our symmetric modes
and effectively whenever we talk about
symmetric encryption
most of the cases that we're talking
about are
block ciphers at least most of the
modern ones are
and this means that it takes a certain
amount of data it encrypts it and then
moves on to
another block of that certain amount of
data so it could be 8
bytes might be 16 bytes whatever it is
we have to take that data we encrypt it
and then we move on
but it's this kind of iterative process
as we go through it so the question is
is how do we move from one block to the
next and make sure that we're keeping
things secure
and there are a couple of different ways
that we can do this depending on
the goal that you're trying to achieve
so the first way that we do is we just
do the same block over and over again
okay we don't really have any variations
this is called
electro electronic code book mode or ecb
the takeaway from this is that each
block is the exact
same it's encrypted the exact same way
okay and we should avoid this at all
costs for all but the extremely small
messages
and here's why whenever you use
electronic code book mode it's doing
those blocks and
you can actually see in the section that
we have here that it's going through
and it's talking about we have three
blocks
set off with two passwords using the
same key
we have one small change of an s towards
the middle of the password we can see
that only the center section changes
now if you know this the attacker could
use this to change out certain portions
of it if they knew that a certain
portion of the message was valid or
invalid and they could use this for an
attack
so generally speaking we should never
use electronic code book mode
so the next one that comes up is cipher
block chaining or cbc and what we're
doing is we're taking the output of one
process and using that as the input for
the plain text on the other side on the
next process
now what this means is that whenever we
go through we can encrypt
using a single thread but whenever we go
to decrypt we can do it in parallel
so it allows us to go through and find
those pieces and carry them
over as part of the next process it
allows us for
for us whenever we have a full series of
blocks encrypted
to do random seeking in that space
so the next one is cipher feedback and
cipher feedback
is another one that goes through and it
takes the information out
and it supplies it going into the blocks
now
encryption can't be paralyzed in this
case but decryption
can be um and this again allows for
random seeking through the data that's
been encrypted
the next one is output feedback mode and
effectively this sets it up in such a
way that the output from one is included
as part of the
entry point for the next one now what
this means
is that we have a stream that goes
across and this effectively creates that
streaming process
data has to come in one side go out the
other side we can't paralyze the
encryption or decryption
um and it doesn't allow for random
reading but the key feature of this is
that
if somebody starts listening in the
middle of the conversation
even if they have the initial key they
probably aren't going to be able to
start listening back in on that
conversation okay the last one is
counter mode encounter mode uses a nonce
as a counter to increment the
initialization vector
now the value to this of course is that
the encryption can be
done in parallel the decryption can be
done in parallel and it allows for
random reading as part of the process um
you know as we talk about legacy
products and the the kind of pieces that
are in there
there's some very dangerous pieces of
our algorithms that are out there that
have been around for years and are used
in products
um that we need to pull out and so i'm
again i'm not going to drain this slide
for you but
here's kind of an idea of what we're
looking at and when it should have been
removed from your product
if you see any of these in your product
just go through and replace them with
some of these okay and there's some good
advice out there for which are the
algorithms to use and how to use them
um but generally speaking aes is going
to get you most of the cases if it
doesn't
um there are some other options
available to you
so this brings us to asymmetric
encryption
asymmetric encryption is really our
traditional alice and bob
story we've got two people who want to
share
information between each other and they
want to do it in such a way that they
don't
risk losing information as part of the
process
and to do this we have two pieces we
have this idea of a public
key and a private key and the public key
can be shared with
anybody this is completely open public
knowledge
anybody can have it and the idea is that
if
i want to send this send a message to
somebody
who is using that public key all i have
to do is get a copy of that public key
take my message encrypt it using their
public key and their cipher text on the
other side
now the interesting part about this is
that is that i can't
you know i can pass this text around and
if they only have the public key they
should not be able to get
the information out of the message that
went into it
so it should be safe for everybody to
have a copy of it
save for bob and then when bob gets it
bob actually has the tool he has that
private key
to take and decrypt the message using
the cipher text
and usually a password protecting bob's
private key
so you have two layers of protection one
they have to have physical access to the
key
but two they also have to have the
password to unlock it so it's something
they haven't something they know
and that ends up producing this text
back again
so why do we use asymmetric data
encryption
uh really it serves two really good
purposes for us
the first one is it ensures that data
can always be decrypted by the right
people
and assuming that it has decrypted on
access
um so assuming that they're using a
password for this to unlock that private
key
we can actually go and say at a high
level that we
feel more secure that this person is the
person who should be reading it
um because you theoretically in this
space if you have an encrypted message
and they steal the private key if they
don't have that password to unlock it
that should be only in the person's mind
and they should be the only person who
has it
um in that instance only then should
they be able to open it up and decrypt
it
okay and additionally we have this kind
of element of
integrity which means i can say that if
i know that i'm keeping my private key
safely and i want to prove
that i generated something i should be
able to
sign a copy of something using my public
key in this case or
using a signing key pair i should say
to prove that i was the one who
generated this message
i can send it out so that everybody can
decrypt it
but since i was the only one who was
able to encrypt it
we know that the message came from me
and we can use that to validate that the
source of the data was exactly what we
thought it was
okay so signing really works in this
function
and it uses uh is used for you know
for us being able to validate things and
we see this in a lot of cases
um you know tools like generating uh
jwts and things like that will allow us
to use
encryption to verify that the source of
the data was original
okay so we take some data we take a hash
and then we go through and we sign that
hash and now we have the ability to say
if i ship the data that original portion
of
corporate ipsum with that hash and that
message
i can now say that this data that i sent
you is correct
by value of the fact that i ran this
hash through it
got a value that was cryptographically
sound
and then signed that and sent that to
you now you have verification that not
only the data that was sent as part of
the package was correct
but also that i was the one who said it
was correct
okay um which brings us to the point
where we start actually talking about
algorithms and there are two main
algorithms in this space that we can
talk about um the first one is
rsa and rsa was originally designed in
the 1970s
and the math behind it basically relies
on the fact
that factoring really really large
primes
is very difficult and time consuming to
do
now the key to this is that it really
gives us a space where
as we scale up on this it gets more and
more difficult to try
and guess those keys and so at low
bit rate for the keys we run into
problems
so for example 256 keys can be broken in
about 35 minutes
10 24 is really kind of that minimum
considered to be secure
you really want to be at 2048. but once
we get up to
4096 we've got something that's fairly
resilient going forward
but runs into the problem that
generating keys of that size is a
very very time consuming process
and the further we go up that the
processing time necessary to generate
larger keys gets
exponentially larger as we go up through
this
um and so it's both a blessing and a
curse in that way that we have something
that you know gets more difficult to
process that way but becomes more
difficult for us to generate
um generally speaking when you hear
about uh quantum
quantum affecting cryptography this is
usually what they're talking about
because the properties of quantum
computers are such that they will allow
for the
quick factorization of prime numbers
which
could put rsa at risk
so so what do we do to shift away from
that
we have what's called elliptic curve
cryptography
and really it addresses a lot of these
underlying pieces and really ecc
is very fast it's structured so that it
can be run on very low
performing hardware and it's generally
considered to be
pretty strong against future
incidences of you know quantum
cryptography problems right
um so generally speaking whenever we're
looking at doing public key private key
now we really want to go in
and we want to be doing elliptic curve
okay
but there are some things that you have
to know about elliptic curve and it can
get
really kind of challenging to go through
this process
uh there's a website that will give you
a list of safe curves to use
and they go through and they list all of
these um the final note on this is
probably
you know i i personally can't tell you
whether you should be using them or
shouldn't be using
them whether they're safe or whether
they're not safe there's a lot of
question in that space
as to what constitutes safe or unsafe um
but if you want to avoid that
conversation altogether
uh just don't use those um there are two
really good curves out there
um the first is curve two five five one
nine
um which is generally considered a
really good one or
p256 and both of these uh depending on
the hardware that you're looking at may
actually have
hardware acceleration that really pushes
that to the next level
um generally speaking those are going to
be the two that you're going to want to
use if you need something that's got a
kind of a higher level of security
um and you're willing to burn off a
couple extra cpu cycles to make it work
uh ed448 goldilocks is a good choice
okay but say you know we've got
symmetric key encryption which is really
good for transferring information
quickly
and encrypting large amounts of data
using private key
private public key is really slow how do
we
kind of bridge that gap and generally
when we do that we talk about hybrid
encryption
and what we have is we have two groups
that have their public keys and private
keys
and we go through a key negotiation
process where we generate
a random key and then we encrypt the
bulk of the data that we want to
you know pass back and forth between us
with that key
and then we wrap it up in the public key
private key exchange
and so what we'll do is we'll take and
we'll transfer the data
and when we're done with that we'll take
and we'll transfer the key
to that data using public and private
key cryptography
that way we effectively have a balance
of data that's transferred to one
place to another safely and then is
decrypted once
the party that we know is going to be
receiving it
decrypts that random key for the
symmetric portion and then can decrypt
the main part the of the payload um
and that's really what we talk about
whenever we talk about hybrid encryption
okay so this kind of brings us to the
last piece right we've talked some about
encryption we've talked some about
hashing we've talked some about
passwords and all of this but you know
anytime we talk about encryption
you know the problem comes of the key
right
somebody inherently has to know the key
and some
where somebody has to be able to hold it
otherwise we can't use it right
so where do we put them um generally
speaking your encryption's only as good
as your storage key
and what you're doing with that can make
it either stronger
as far as the protection or really
weaken it and so
when we talk about this some really bad
places to store encryption keys are
things like
in docker secrets um so first of all it
should be known that docker whenever you
do a docker secret is only base64
encoded
so that's not really encryption at all
um but if
assuming that you go through and encrypt
your data in the secret and then you put
that secret in
a base64 encoding and then store it in
there it's still not safe you don't want
to stick
your encryption keys in docker or
kubernetes at all web configs or other
similar config files
is generally also a bad idea don't and
put these keys in source code if you've
got
questions about how easy it is to
disassemble something
um it's painfully easy to get a hold of
your code
and disassemble it um don't stick it in
environment variables um because
attackers have
if they get access to the environment
they also have access to those variables
um generally speaking don't stick them
in databases one of my favorite stories
is i had a group that came to me and
showed me their database structure and
they said okay all of our data is safe
now everything's
safe and secure and i said well yeah it
kind of is except for
you know you could get in to your system
by a sql injection
and on each row it has a row encryption
key
as one of the columns so they don't
store it in the database
they can get access that's where it's
going to be um
don't stick keys in open memory this is
kind of a tough one for a lot of groups
to kind of really wrap their minds
around
effectively what happens is even when
you're pulling these things into memory
somebody can dump the memory of your
application get those debug
pieces and dump your application and
pull that out
and so we want to make sure that
whenever we handle that we don't want to
have our encryption key sitting out
there because that's effectively giving
away the data
under no circumstances ever stick
secrets into source control
this is a horrible idea um encryption
keys those type of things have no place
in belonging anywhere in your data
whatsoever
build servers the number of teams that
i've seen sticking
you know encryption keys and secrets in
build servers is an awful idea
don't do that um good places to stick
encryption keys if you're on a device
having the tpm generate a key or
generating a sub key from a key that's
stored in tpm is a fantastic way
to ensure that that key is held securely
um
inside operating systems they're usually
credential management systems
you know it's better than storing them
directly on the hard drive but
still not quite the same level um
if you're in cloud environments or
you're gonna on prem a key vault can be
a fantastic
option and so what that does is it
allows you to
segregate your encryption keys away from
the rest of your applications
so that it's only available on request
and then whenever you make that request
and whenever you pull it local
use secure strings most of those are
built into application to
application frameworks to allow the safe
containment of secrets
it's not great but it adds an extra
level of difficulty into extracting them
so if you want additional reading in
this space i would strongly recommend
picking up a copy of applied
cryptography it is a fantastic book
despite its age hopefully we will get a
third edition at some point
um additionally we have practical
cryptography developers
currently the entire book is as much of
it
as written is currently available on the
web and definitely thank you for that
um with that said i would like to thank
you and i will be around to take
questions uh thank you very much