Security notes / Unsorted

Security related stuff. Linux - PAM notes · SELinux Securing services Public key encryption; SSL and TLS SSH: tunnels, X forwarding · keypair logins · SSH jails · loose notes · agent Apache config and .htaccess - security A little more practical security for the everyday person not-so-formal notes Ingredients that might be useful to know - MFA / 2FA · One-Time Passwords; also, authenticators 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 — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Pre-boot authentication

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

JSON Web Signature, Encryption, Tokens

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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)

Side notes

Asymmetric v.s. symmetric keys

Some systems have a single key, that can be used both to encode and decode - which we would call symmetric encryption.

Yes, it allows encryption in both ways.

But only if both parties trust each other mutually.

Everyone with that one key can do all the writing messages, and reading, so that key must stay secret -- but it you never really trusted the other party, then arguably it never was.

If hat key ever gets accidentally or purposefully leaked elsewhere,

writing messages now probably means 'impersonating any party involved',

and reading messages potentially means 'reading all messages, past and future'.

Sharing the same key between more than two is as weak as the weakest link. In some ways, two is usually the limit that you would prefer.

Public-private key have upsides beyond fixing this, but there are many situations where this is the main thing: even the strength of its encryption can be entirely secondary that you don't share all abilities from the get-go.

Consider:

you can only write messages with the private key

you can read messages with the public key

given the public key of someone's (public,private) keypair, it is nearly impossible to calculate the private one

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