Security notes / Unsorted: Difference between revisions
(4 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{#addbodyclass:tag_tech}} | |||
{{#addbodyclass:tag_security}} | |||
{{SecurityRelated}} | {{SecurityRelated}} | ||
{{stub}} | {{stub}} | ||
Line 252: | Line 254: | ||
==Side | ==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'''. | |||
<!-- | |||
Aside from some potential weaknesses about ''how'' that key is used, there is a more fundamental thing to think about. | |||
--> | |||
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 | : 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. | |||
...which is why it isn't a problem to hand the public | |||
Revision as of 14:42, 15 May 2024
Security related stuff.
Securing services
Unsorted - · Anonymization notes · website security notes · integrated security hardware · Glossary · unsorted |
Pre-boot authentication
https://en.wikipedia.org/wiki/Pre-boot_authentication
Nonce
Challenge/response
JSON Web Signature, Encryption, Tokens
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 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.