882 reputation
611
bio website michael.kjorling.se
location
age
visits member for 3 years, 6 months
seen 2 days ago

Oct
15
revised SSL3 “POODLE” Vulnerability
Also two-exponents
Oct
15
suggested suggested edit on SSL3 “POODLE” Vulnerability
Oct
13
comment What is the difference between a key algorithm and the encryption algorithm?
Also, don't forget that often encryption and signing is used together. Since signing uses the (encrypted, password-protected) private key, the software would need to prompt for the private key's passphrase, even though the private key is not used for the encryption process per se.
Sep
29
comment Mapping of plaintext and ciphertext in DES
@Mark Fair enough point. How about now?
Sep
29
revised Mapping of plaintext and ciphertext in DES
added 585 characters in body
Sep
28
answered Mapping of plaintext and ciphertext in DES
Sep
28
answered HTTPS self signed certficiate for personal website
Sep
26
comment Four-factor authentication
While this answer may be true, I don't really see how it answers the question of whether there exists a fourth class of authentication factors. Care to edit to elaborate on that part?
Sep
17
comment Is SHA1 weak for SSL?
This answer effectively says "X is, because Y does Z because X". The answer to "why does Entity X say Y is Z?" can't be simply "Entity A is Act B because C", where C = Z (Qualys are saying SHA-1 based certs are weak because Google is going to warn about them because they are weak). The answer would be C' = Z' where those are the reason entities A and X are stating C and Z, respectively.
Sep
2
suggested suggested edit on Unix execute permission can be easily bypassed. Is it superfluous, or what's the intention behind it?
Sep
2
comment Why is security through obscurity not a good option for encryption?
Actually, this is not correct. A basic underlying assumption of any symmetric crypto is that the sender and recipient (whether different entities, or the same entity separated in time or space) shares a secret. (In the case of most modern algorithms, that secret being the key.) How to establish such a shared secret is a separate problem, and it can be done using techniques like public-key cryptography, pre-shared secrets, and so on.
Sep
2
comment How valuable is secrecy of an algorithm?
Now, designing something such that it can be made public without severly impacting security, and actually making it public, are two different things. Look at today: I have little doubt that the vast majority of the security in military encryption rests in the key (and key distribution), but that doesn't mean that every military encryption algorithm is made public as due course, only that if that were to happen security would not be greatly adversely affected. Particularly in such situations, there is no need to make things easier for your adversary than you need to.
Sep
2
comment How valuable is secrecy of an algorithm?
@FelixDombek If the Enigma had been designed from the ground up to be a published design, and for its security to lie in the key, the efforts to crack it would have had to focus on the key rather than the machine. In that case, even having access to Enigmas would have removed the need to build any, but it would not fundamentally have changed much: you'd still have needed to break the key, and with a good algorithm, that basically means trying every possible key. Make the key long enough and that simply is not feasible. Keys are also in some ways easier to safeguard.
Sep
2
comment How valuable is secrecy of an algorithm?
Changing the internals of the Windows password hashing scheme (if that is done; I don't know) also prevents software vendors from relying on a particular scheme being used. That might actually be quite worthwhile in itself, even if the exact algorithm was public. Note that anything officially documented is generally considered by contract from the vendor who documents it, and thus cannot easily be changed in the future if there is ever a problem with that design.
Aug
29
comment What is the point in having arbitrary username requirements?
This to me appears to not be about prevention, it's about mitigation. Prevention would be perhaps blocking multiple sequential attempts (maybe by making each attempt take some non-negligible amount of time and only allowing a certain low number of outstanding attempts per remote IP address). Mitigation might be making credentials less guessable, causing an attacker to have to rely on other tactics. Now, both potentially have value, and the distinction isn't always very clear-cut, but they are separate points to consider.
Aug
29
comment What is the point in having arbitrary username requirements?
I would argue that if a bank (or other financial institution) doesn't have systems in place to detect a large number of sequential failed logins, even if the attempts are to different accounts, that's a problem in itself. Obscuring user IDs doesn't really help mitigate the underlying problem, which is a failure in monitoring.
Aug
22
comment Downsides to using HTTPS
Don't forget Cache-Control: public which can help, as long as the cache can act as a HTTPS endpoint.
Aug
20
revised How to establish a random OTR remote party as a specific individual?
added 41 characters in body
Aug
12
comment Why not use larger cipher keys?
OK, well, even within the exact same algorithm (and out of the examples already cited), we've still got AES which can use several different key sizes but always the same block size. Or Blowfish, which has variable key size and fixed block size.
Aug
12
comment Why not use larger cipher keys?
"block sizes of the symmetric algorithms, which als grows with the key length" That is not necessary. DES: 64 bit key (minus eight bits ignored), 64 bit block. IDEA: 128 bit key, 64 bit block. AES: 128, 192, 256 bit key, fixed 128 bit block. Blowfish: up to 448 bit key, fixed 64 bit block. RC5: up to 2040 bit symmetric key, 32/64/128 bit block (selectable, 64 bit block suggested). And so on.