Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
earthrise
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
1.
▲
A Plausible Reason It's So Hard to Prove P =NP
(defuse.ca)
4 points
by
earthrise
5y ago
|
0 comments
2.
▲
Time Capsule: Send a Message to the Future
(defuse.ca)
2 points
by
earthrise
9y ago
|
0 comments
3.
▲
by
earthrise
9y ago
This post really needed to be written -- I get this question a lot, too. I like the blind indexes concept, it saves you from having to find some weird deterministic encryption mode (like using an HMAC of the message as the CBC mode IV or so
4.
▲
by
earthrise
9y ago
Security is half a technical problem and half a usability problem (for developers). We need more emphasis on the usability half. For example, we should be doing everything we can to ease the mental burden of writing secure code. Whenever we
5.
▲
Is Quantum Key Distribution Worth Using?
(bqp.io)
2 points
by
earthrise
10y ago
|
0 comments
6.
▲
Gocryptfs Security Audit
(defuse.ca)
3 points
by
earthrise
10y ago
|
0 comments
7.
▲
by
earthrise
10y ago
The salt would need to be kept secret so it shouldn't be called a salt, it should be called a key. The benefit of Scott's solution compared to this is that you don't need to deal with all the usability problems associated wit
8.
▲
Will we ever solve the hard problem of information security?
(bqp.io)
1 points
by
earthrise
10y ago
|
0 comments
9.
▲
Mandatory Backdoors Are a Tax on Encryption
(bqp.io)
3 points
by
earthrise
10y ago
|
0 comments
10.
▲
Password Hashing Competition winner and special recognitions
(groups.google.com)
89 points
by
earthrise
11y ago
|
21 comments
11.
▲
by
earthrise
11y ago
I usually consider this a "vulnerability" in the sense that the author probably intended to use AES and so they may have misunderstood the mcrypt API. Most importantly, they might have wanted AES-256 and missed the fact that mcryp
12.
▲
Reasons to Avoid Mcrypt
(appsec.solutions)
16 points
by
earthrise
11y ago
|
4 comments
13.
▲
by
earthrise
12y ago
Yeah, when I made this program two years ago I never intended it to be taken this seriously. I added a big disclaimer to the readme.
14.
▲
by
earthrise
12y ago
Hi everyone, I'm the author of that software. I really didn't want this to blow up. It's absolutely NOT a solution to getting raided by the police. While that was the original inspiration for writing the tool, I was half-joki
15.
▲
by
earthrise
12y ago
Say we're trying to download the PHP source code from php.net. If all that's protecting us is SSL, then if an adversary compromises the php.net servers (happens all the time, and actually has happened to PHP), they can immediatel
16.
▲
by
earthrise
12y ago
I've written down some general principles we should follow, but any reasonable implementation of them seems pretty far off: https://defuse.ca/triangle-of-secure-code-delivery.htm tl;dr: (1) Reproducible builds, (2) Mak
17.
▲
Sodium in PHP: Asymmetric Crypto, Hold the Blood Pressure
(scott.arciszewski.me)
4 points
by
earthrise
12y ago
|
1 comments
18.
▲
Triangle of Secure Code Delivery
(defuse.ca)
1 points
by
earthrise
12y ago
|
0 comments
19.
▲
The Sinking Ship of E-Mail Security
(adamcaudill.com)
36 points
by
earthrise
12y ago
|
54 comments
20.
▲
by
earthrise
12y ago
Steve Gibson is working on a system called "SQRL" that does exactly that, and should be very usable: https://www.grc.com/sqrl/sqrl.htm edit: forgot some words
21.
▲
by
earthrise
13y ago
Here's the rough process I followed when I did that audit: https://defuse.ca/b/hwwW9d3FkPGhM4T6xBIbhf I think the reason I found so much in only 10 hours is that I had a good set of guesses about what could be wro
22.
▲
P=NP in the Star Trek universe
(scifi.stackexchange.com)
2 points
by
earthrise
13y ago
|
0 comments
23.
▲
by
earthrise
13y ago
In cryptography, the burden of proof is on the one proposing the system. It's up to the system designer to prove it secure. The reason why we stick to things like encrypt-then-HMAC, rather than rolling our own protocol, is that they HA
24.
▲
by
earthrise
13y ago
This is a bullshit challenge. The attack model in which it is set is nothing like the theoretical models cryptographic systems are designed to be secure against, and even less like how crypto software is actually attacked in practice. There
25.
▲
Gridlock
(en.wikipedia.org)
2 points
by
earthrise
13y ago
|
0 comments
26.
▲
by
earthrise
13y ago
Feature request: Search by address.
27.
▲
THIS IS A BUTTERFLY (Scanning Electron Microscope)
(youtube.com)
1 points
by
earthrise
13y ago
|
0 comments
28.
▲
Shaft passer
(en.wikipedia.org)
199 points
by
earthrise
13y ago
|
65 comments
29.
▲
by
earthrise
13y ago
I think in the long run (repeat the process hundreds of times), there would still be an advantage to the selfish miners. Edit: Here's a simulation written by Dan Kaminsky. http://pastebin.com/PfBhLc7r
30.
▲
by
earthrise
13y ago
I haven't read the paper, and I'm certainly no expert in game theory, but I don't think we have to worry too much about this. The assumption seems to be that selfish miners will collude to control the network. However, it s
More ›