4 ms·
If anything, I would use a lock analogy. Locks are rated in how many seconds/minutes they can withstand from a dedicated attacker. Perhaps that would be a way
by kefka 10y ago
If anything, I would use a lock analogy.
Locks are rated in how many seconds/minutes they can withstand from a dedicated attacker. Perhaps that would be a way to determine a similar safety rating for passwords/crypto based systems.
In passwords: how many passwords can you try per second before the server refuses? Then Password space/# per second = total seconds for guaranteed entry.
Crypto: how many keys do you have to calculate before you succeed in finding the correct key? Keys/second * how many machines / keyspace.
But in the end, I don't believe we really have a formalized difference between types of obscurities, aside the "go to /root and get root" obvious badness. It would be a rather nice way to provide security in "seconds to millenia depending on techniques used".
- kelson 10y agoWe measure password and cryptographic key security based on their entropy (keyspace) and speed (key tests / second). Given current attacks (GNFS), a 2048-bit RSA key has ~112 bits of security^1 and would take ~20,000 years to brute force using every computer ever made^2. Passwords and cryptographic keys are selected as the single point of obscurity in these systems so that many eyes may secure the other components. If the system is otherwise secure, then it is as weak as the passwords/keys which are (hopefully) picked to be very strong. Most individuals defending algorithmic security through obscurity believe that hiding the algorithm improves security. That may be true in an extremely technical sense (the attacker must recover the algorithm first), but it is very misleading and unprofessional commentary. Algorithmic security through obscurity is at best calculated in difficulty-to-reverse-engineer (or difficulty-to-steal), which doesn't provide per-use(r) specificity (per-user password) nor scale in complexity (a 256-bit key is generally 2^128 times stronger than a 128-bit key, but doubling the algorithm length increases reversing time by slightly less than a factor of 2). Algorithmic security through obscurity provides negligible security, but what's the harm? Why should we care? Attempting to hide the algorithm provides a false sense of security, limits review to "approved" parties, and induces legal/social efforts to "protect" the secret. The limited review is particularly noteworthy since it promotes bugs in both the algorithm and the implementation. The end result is a facade of security, some very unhappy whitehats, some very happy blackhats, and more users betrayed through poor security practices. [1] http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_p... [2] http://tjscott.net/crypto/64bitcrack.htm#INTELG http://tjscott.net/crypto/64bitcrack.htm#INTELG