Security notes / Encryption notes: Difference between revisions

From Helpful
Jump to navigation Jump to search
(Created page with " ==data-at-rest encryption versus encrypted transfers== <!-- '''Data-at-rest encryption''' mostly refers to encrypting files, partitions, or entire drives. It does absolut...")
 
mNo edit summary
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{#addbodyclass:tag_security}}
{{#addbodyclass:tag_tech}}
{{SecurityRelated}}


==data-at-rest encryption versus encrypted transfers==


==data-at-rest encryption versus encrypted transfers==


<!--
<!--
We really ought not to say just "encryption",
because there are distinct types that, in a very mechanical sense,
: have completely different uses, and
: have completely different challenges when it comes to ''making'' them secure at all,
: have completely different challenges to ''keeping'' things secure over time.
And when we say 'different', we mean both
: theoretically distinct (e.g. at-rest encryption versus encrypted transfers; symmetry versus asymmetry; the math of key exchange)
: and practically distinct (encrypted connections based on managing keys, versus public key infrastructure)


'''Data-at-rest encryption''' mostly refers to encrypting files, partitions, or entire drives.
'''Data-at-rest encryption''' mostly refers to encrypting files, partitions, or entire drives.


It does absolutely nothing to keeping that data private while it is in a usable state.
Usually: once it's powered off, it is unusable until a specific action/secret is given
 
Data-at-rest encryption is great for peace of mind around theft of hardware.


It does absolutely nothing to keeping that data private while in transit.
But it applies only to local storage while powered off:
* It does absolutely nothing to keeping that data private while it is in a usable state


* It does absolutely nothing to keeping that data private while in transit.




'''Encrypted transfers''' refers to setting up a network transfer that cannot be snooped on.


It does absolutely nothing to keeping that data private on the endpoints that are communicating.
'''Encrypted transfers''' refers to setting up a network transfer where snooping on it would give the snooper ''nothing''.


('''End-to-end encryption''' often refers only to encrypted transfers. It sometimes means more, but don't assume it until you've checked.)


The wording intentionally points out that these two solve completely different things,  
This is great great when you don't trust the network you're communicating on - and when in doubt, you shouldn't -  
and are almost completely non-overlapping.


These two solve different issues, and have their own designs, and their own challenges.
But it applies only to transit:
* It does absolutely nothing to keeping that data private while/once on the endpoints that are communicating.


* It stops when once that data makes it to the other endpoint; it says nothing about what those endpoints ''then'' decide to do with that data




'''Encrypted transfers''' are great when you don't trust the network you're communicating on.
The wording above intentionally points out that these two are almost entirely complementary.  
Which, in general, you shouldn't.  
They solve completely different things, are largely non-overlapping.  


It often requires a previously shared secret, previously verified exchange (an important detail
They have their own designs, and their own challenges.
that on the internet we often... sort of ignore at our own peril. See [[LARP security]]).


Say, both involve a previously shared secret,
previously verified exchange (an important detail that on the internet we often... sort of ignore at our own peril. See [[LARP security]]),
but exactly who does the checking, and any vouching-for, is different for practical reasons.








Data-at-rest encryption is great for peace of mind around theft of the hardware.


At the same time, this can be overstated/overestimated.
The "data-at-rest encryption is great for peace of mind around theft of the hardware"
That is, you should assume that while unlocked, absolutely everything can read them.  
''can'' be overstated somewhat, in that you should assume that while unlocked,
absolutely everything can be read off.  


For example, the type of full hard drive encryption that requires a pass-phrase at startup
For example, the type of full hard drive encryption that requires a pass-phrase at startup
Line 52: Line 73:
(if someone were interested in the data, they would want to keep it powered on, keep it from screen locking if it wasn't already, and such)
(if someone were interested in the data, they would want to keep it powered on, keep it from screen locking if it wasn't already, and such)


Particularly phones are better than that, but you shouldn't assume it.




-->
<!--
==More theoretical==
Homomorphic encryption
https://en.wikipedia.org/wiki/Homomorphic_encryption


-->
-->

Latest revision as of 16:26, 20 April 2024

Security related stuff.


Linux - PAM notes · SELinux

Securing services


A little more practical


More techincal waffling

Message signing notes · Hashing notes ·
Auth - identity and auth notes
Encryption - Encryption notes · public key encryption notes · data-at-rest encryption ·pre-boot authentication · encrypted connections

Unsorted - · Anonymization notes · website security notes · integrated security hardware · Glossary · unsorted

data-at-rest encryption versus encrypted transfers

Retrieved from "https://helpful.knobs-dials.com/index.php?title=Security_notes_/_Encryption_notes&oldid=95411"