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...")
 
Line 2: Line 2:


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


<!--
<!--


'''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.
Data-at-rest encryption is great for peace of mind around theft of the hardware.


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 it is in a usable state.
Line 13: Line 16:




'''Encrypted transfers''' refers to setting up a network transfer that cannot be snooped on.
'''Encrypted transfers''' refers to setting up a network transfer where snooping on it would give the snooper ''nothing''.


It does absolutely nothing to keeping that data private on the endpoints that are communicating.
('''End-to-end encryption''' often refers only to encrypted transfers. It sometimes means more, but don't assume it until you've checked.)


This is great great when you don't trust the network you're communicating on - and when in doubt, you shouldn't -


The wording intentionally points out that these two solve completely different things,
Yet it's only responsible for protection in transit.
and are almost completely non-overlapping.


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






'''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 57:
(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.




-->
-->

Revision as of 19:03, 10 July 2023


data-at-rest encryption versus encrypted transfers