sdrapkin

8 ms·

31.
by sdrapkin 9y ago
The best (ie. fastest and safest) SHA2-family function is SHA-384. http://securitydriven.net/inferno/#Implementation%20Details
32.
New Micro-ORM for .NET: TinyORM(github.com)
3 points by sdrapkin 9y ago|0 comments
33.
by sdrapkin 10y ago
"The process for encrypting a file: (3) SHA-256 hash the shared secret to generate a 64-bit IV." "The process for decrypting a file: (4) Validate the IV against the shared secret hash and format version." Does anyone els
34.
by sdrapkin 10y ago
An important part of the Signal Protocol is Triple-DH. I did not find a good illustration of how it works, so I made one: https://twitter.com/sdrapkin/status/738419956371628033
35.
SecurityDriven.Inferno (.NET crypto library) has been audited(twitter.com)
2 points by sdrapkin 10y ago|0 comments
36.
by sdrapkin 10y ago
.NET is covered: http://securitydriven.net/inferno/
37.
by sdrapkin 10y ago
I've read the source too. You are strangely looking at EtM_CBC, which is not Inferno's primary mode. Inferno uses EtM_CTR for the "Encrypt" signature you cite. The raw CBC mode is already nonce-misuse-resistant (reveals
38.
by sdrapkin 10y ago
Nonce-exposing high-level crypto APIs are flawed by design. Most developers believe that they need low-level crypto APIs - in fact they get a kick out of coding against low-level crypto APIs. This is a dangerous fallacy/hubris. Most de
39.
NET crypto done right: Inferno library(securitydriven.net)
2 points by sdrapkin 11y ago|0 comments
40.
by sdrapkin 11y ago
Additional evidence of inadequate .NET implementation: There is a ton of code & pointless complexity to minimize the time sensitive data has to remain in plaintext in memory, and zeroing buffers asap. Clearly, the "process memory c
41.
by sdrapkin 11y ago
In my argument I never make a leap from "OSS allows discovery of crypto mistakes" to "OSS must be higher quality" or "OSS is better for the masses than closed-source". In fact, I've never seen more crypto
42.
by sdrapkin 11y ago
You can't expect a closed-source crypto software vendor to hand the source to a 3rd party, but you have no problems handing that vendor's software the keys to your life. I'm not going to debate the merits of that decision, bu
43.
by sdrapkin 11y ago
Guilty as charged on the HMAC'ing the IV verification - bad example for a still-valid point. You still don't know whether closed-source code is using the rng properly, sending "debugging information" containing your priv
44.
by sdrapkin 11y ago
I never claimed or implied that latest design of 1Pass repository is worse or even security-equivalent to KeePass. I simply pointed out that 1Pass team has made their share of mistakes (plural), so I have as much trust in their competence a
45.
by sdrapkin 11y ago
"Clearly, they didn't take crypto design very seriously when they shipped a product based on it." - spot on. There is no deeper subtext. Not sure what you found weird - eridius got my point perfectly and countered well.
46.
by sdrapkin 11y ago
I don't buy this "explanation" for the following reason: Even if they could not anticipate an attacker tampering with user data, surely they should've been able to anticipate filesystem corruption? Let's not pretend
47.
by sdrapkin 11y ago
Fair enough. I do note that the very blog you linked mentions that there are two 1Password formats: 1. The "Agile Keychain Format" (versions 2 and 3, which lack integrity). 2. The "Cloud Keychain Format" (versions 4+, wh
48.
by sdrapkin 11y ago
You store u/p to your Lawyer's website, which has a copy of your Will. You die and the Executor of your Estate tries to access the Lawyer's website, only to be met with "invalid password". It turns out that the kdbx
49.
by sdrapkin 11y ago
Please remember that just because tptacek likes and uses something, do not mean that it has great security. The PDF linked below states that there is zero integrity in 1Password file format. I happen to like and use KeePass, but that is not
50.
by sdrapkin 11y ago
To those who don't see a problem with leaking timing data: KeePass goes to great lengths to do in-memory encryption of data. I'm not saying these attempts are properly done, but there is certainly no lack of trying. The only reaso
51.
by sdrapkin 11y ago
1. It would be nice if someone like CodesInChaos (ie. someone with both crypto and .NET expertise) were to casually audit the KeePass 2.x codebase and do a write-up. 2. It would be nice to create a kdbx 3.0 (ix. next-gen) storage format,
52.
by sdrapkin 11y ago
I have verified that the CryptoRandom class is part of a standalone library with (1) should be thread-safe since it cannot dictate how it will be used by callers; (2) the authors clearly intended this library to be thread-safe (based on &qu
53.
by sdrapkin 11y ago
Step-1: open the above PDF. Step-2: search for "HMAC". Step-3: note which application uses HMAC. Step-4: you should prefer (3) to all others.
54.
by sdrapkin 11y ago
Wrong.
55.
by sdrapkin 11y ago
Because the main login is HTTPS-secure (I would hope - for a bank), but the change-password feature is not.
56.
by sdrapkin 11y ago
Philbarr is correct. The pattern they are using is fundamentally supposed to provide a thread-safe Singleton, and it fails to do that. Is that a security problem in this specific context? No. But it's a "No" because the autho
57.
by sdrapkin 11y ago
Any takers on that question?
58.
by sdrapkin 11y ago
I notice that the "change-password" function of yourbank.com is accidentally being served over HTTP instead of HTTPS. I just need to trick you into changing your password. I have access to your kdbx db (ex. you sync to Dropbox and
59.
by sdrapkin 11y ago
There are 2 problems here. (1) The c# .NET implementation is lacking; (2) the fundamental crypto design of the kdbx database (which is shared by all implementations, in any language) is lacking.
60.
KeePass – questionable security
366 points by sdrapkin 11y ago|221 comments

More ›