Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
xnyhps
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
14 ms
·
91.
▲
by
xnyhps
12y ago
Looks like it isn't: https://github.com/erming/shout/issues/52
92.
▲
HTTPS Attacks and XMPP 2: CRIME and BREACH
(blog.thijsalkema.de)
10 points
by
xnyhps
12y ago
|
0 comments
93.
▲
CVE-2014-1361: SecureTransport Buffer Overflow
(blog.thijsalkema.de)
2 points
by
xnyhps
12y ago
|
0 comments
94.
▲
by
xnyhps
12y ago
Let me shamelessly post this again: https://blog.thijsalkema.de/blog/2014/04/02/breaking-half-of... Even if you'd consider their protocol secure enough (which I don't), this third-party app was
95.
▲
by
xnyhps
13y ago
I've been looking into what options exist and what their pros and cons are for switching LuaSec from OpenSSL to something else (mostly in the context of Prosody's TLS support). These are my pros and cons so far, but it's a pr
96.
▲
Breaking Half of the Telegram Contest
(blog.thijsalkema.de)
80 points
by
xnyhps
13y ago
|
33 comments
97.
▲
by
xnyhps
13y ago
The assumption that JS is more secure than C.
98.
▲
by
xnyhps
13y ago
Getting carriers on board to make a texting replacement? Well, you can dream. ;)
99.
▲
by
xnyhps
13y ago
Not if you want it to be “SMS based”, by which I mean: use phone numbers as identifiers. A server can’t easily prove to another that it serves the user with a specific phone number. There’s no cryptographic proof possible, there’s no hostna
100.
▲
by
xnyhps
13y ago
When I looked at it (which is already a couple of months ago), federation wasn't “just works™”. A new server needed to be explicitly permitted into the federated network by WhisperSystems. Every server has a full copy of the list of cl
101.
▲
by
xnyhps
13y ago
I don't think there ever was a serious risk for that for WhatsApp: multi-device support isn't just missing, they are actively making it a pain. There's no way to obtain your password, the password changes regularily, logging
102.
▲
by
xnyhps
13y ago
> OTR uses DH in a ratcheting protocol that requires attackers to continuously break new DH exchanges; it's not like TLS, where one exchange at the beginning of the session gives you the whole session. Please correct me if I'm
103.
▲
by
xnyhps
13y ago
Synchronizing that info accross your devices is exactly something you'd need a protocol for. If you want to preserve the forward-secrecy that OTR offers, then you can't just "encrypt, upload" on one client and "down
104.
▲
by
xnyhps
13y ago
> (btw there's nothing stopping you from adding OTR support to one of the open, reverse engineered, whatsapp clients) Except, you know, DMCA notices: https://github.com/github/dmca/blob/master/201
105.
▲
by
xnyhps
13y ago
Adium 1.6 will include libotr 4, it's already implemented in the nightlies.
106.
▲
HTTPS Attacks and XMPP 1: BEAST
(blog.thijsalkema.de)
1 points
by
xnyhps
13y ago
|
0 comments
107.
▲
by
xnyhps
13y ago
> Just looked up CRAM-MD5, and the password is used as a key to HMAC-MD5, which means you can at least store MD5'ed versions of the passwords. In real CRAM-MD5 this is not true. It uses HMAC-MD5 of the key directly. To be able to c
108.
▲
by
xnyhps
13y ago
> so we've had a solution to the credential sniffing for 10+ years: our services support AUTH via something very similar to CRAM-MD5. Interesting. This suggests you're storing all passwords in plain, is that true?
109.
▲
by
xnyhps
13y ago
My claim is: FS does not imply, by definition, that every attack scales linearly in the amount of keys. Having a counter-example of an attack that does scale linearly does not disprove that point. I indeed only cover DH at #2, as index-ca
110.
▲
Misconceptions About Forward Secrecy
(blog.thijsalkema.de)
50 points
by
xnyhps
13y ago
|
9 comments
111.
▲
Using the Telegram client tg? Regenerate your secret chat keys
(github.com)
1 points
by
xnyhps
13y ago
|
0 comments
112.
▲
by
xnyhps
13y ago
I think it's a brilliant move from the people behind Telegram: all cryptographers will now keep the vulnerabilities they find to themselves until March 1st. This saves them from a lot of bad press now, and probably doesn't cost th
113.
▲
by
xnyhps
13y ago
I really don't know how well the required operations execute on a GPU. I've only skimmed the RSA 768 paper to find that line.
114.
▲
by
xnyhps
13y ago
Yeah, when I started actually trying to back it up, I noticed I was probably a factor 5 off. Namely, if you look at the keylength.com values for asymmetric key sizes, 768 in 2009 ago should come close to the difficulty of 896 today. The RSA
115.
▲
by
xnyhps
13y ago
Well, not entirely the same framing. For $200k one could probably brute-force an 896-bit RSA key. ;)
116.
▲
by
xnyhps
13y ago
Even WA doesn't roll their own key deriviation scheme, they use PBKDF2+SHA1.
117.
▲
by
xnyhps
13y ago
It is possible this is to stop misrouted messages, however, they didn't add it in response to the recent problems. There are some Google hits from 2007-2008 where the field was present, for example https://developer.pidgin.i
118.
▲
by
xnyhps
13y ago
That doesn't refer to any intent on Google's side.
119.
▲
by
xnyhps
13y ago
Where do I claim Google is doing it intentionally to help government intrusion? The paragraph about law enforcement is only meant as an example of how signing can be used against you. The point there is that it doesn't even need to be
120.
▲
by
xnyhps
13y ago
That makes sense if there is a dispute between you and Google. But if the dispute is between you and one of your contacts instead, to claim that the signature is forged would be to claim that your contact has Google's cooperation. That
More ›