Security notes / Unsorted

From Helpful
(Redirected from TPM)
Jump to navigation Jump to search
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

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)


Pre-boot authentication

https://en.wikipedia.org/wiki/Pre-boot_authentication

Nonce

Challenge/response

JSON Web Signature, Encryption, Tokens

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

GSSAPI notes

GSSAPI is a IETF standard to make it easier for various software to do various strong auth, e.g. Kerberos.

It also allows various other auth schemes to be plugged into it.


Which also makes it potentially interesting for SSO setups within an organisation.


(not unlike SASL, which can include GSSAPI)


It's used by things like OpenSSH,

NaCl

There are two security related things called NaCl - which are completely unrelated to each other.

(There are also other things called salt, like automation software Salt (a.k.a. Saltstack)


NaCl as in libsodium

Google NaCl

Side note: Asymmetric v.s. symmetric keys

Simpler systems had symmetric keys, meaning that the encoding and decoding key was the same.


This allows encryption in both ways -- and that both parties have to trust each other mutually.

You have to trust neither will accidentally or purposefully leak the key, because that key means all possible abilities including

reading received encrypted data from, current or past
imitating the other side's data





That's usually fine between two parties, but sharing the same key between more than two is as weak as the weakest link. Again,

reading all parties' encrypted data from, current or past
imitating all parties involved


This is arguably the largest problem that public-private key systems target (there are other upsides):

given the public key of someone's (public,private) keypair, it is nearly impossible to calculate the private one
ideally even with any number of encrypted messages

...which is why it isn't a problem to hand the public ones out.