cryptbe

9 ms·

91.
by cryptbe 12y ago
Not a stupid question at all. We actually considered this option, but OpenPGP.js looked pretty bad back then. Security-wise the library wasn't in good shape. One of our cryptographers would "classify [OpenPGP.js] as trash". I
92.
by cryptbe 12y ago
It supports Curve25519 and Ed25519: https://code.google.com/p/end-to-end/source/browse/javascrip... and https://code.google.com/p/end-to-end/source/browse/javascrip...
93.
by cryptbe 12y ago
Disclaimer: I contribute to the core crypto library in Google End-To-End. I was also a student of Prof. Boneh. I took his CS255, and became a TA for his infamous's Crypto I class on Coursera. So I guess at the end of the day it's
94.
by cryptbe 12y ago
> We know the NSA has found weaknesses in certain implementations of elliptic-curve based cryptography in the past No, we don't. Even djb wants people to use ECC. Note that End-To-End supports not only NIST's curves but also dj
95.
by cryptbe 12y ago
The extension encrypts and saves the drafts in localStorage.
96.
by cryptbe 12y ago
I wrote this blog. I found the mistakes in other people's code, so I didn't complain for myself.
97.
by cryptbe 12y ago
Ha. This is probably something that we mountain view folks would enjoy working on :-). I've updated my blog on how to recover the private key from the CRT parameters stored in the private key: http://vnhacker.blogspot.com&#x
98.
by cryptbe 12y ago
Yeah, you're correct. So it seems that you don't need math to solve this challenge, but maybe luck and patience.
99.
by cryptbe 12y ago
I wrote a tool some time ago. It's 10 lines of Python using pyasn1.
100.
by cryptbe 12y ago
You don't need to use p or q. See http://vnhacker.blogspot.com/2014/04/idea-to-solve-cloudflar...
101.
An idea to solve the CloudFlare Heartbleed challenge(vnhacker.blogspot.com)
2 points by cryptbe 12y ago|0 comments
102.
by cryptbe 13y ago
I don't know why the authors didn't make a website for the SCISSOR attack (a.k.a the cookie cutter attack in the paper), which is way more practical and (imho) much cooler than this session resumption thing. The idea of that attac
103.
by cryptbe 13y ago
My take on PAKE: it's a way to establish a shared key (KE), authenticating each other with a password (PA). The shared key could then be used to build a secure channel. Believe it or not, I've seen many people thinking that KE alo
104.
by cryptbe 13y ago
tlslite is very neat. it must be super hard for me to work on tls without it. > virtually every modern TLS break came from ideas that Perrin popularized oh i didn't know this. what are the ideas?
105.
by cryptbe 13y ago
Thanks. > And of course, there are VPN tunnels between data centers in addition to the above. Could you please be more specific on the VPN solution that you are using? How do you manage the shared keys? How do you make sure 'system
106.
by cryptbe 13y ago
could you share which technology are you using to encrypt all the traffic?
107.
A quick audit of CryptoCat's elliptic curve crypto(vnhacker.blogspot.com)
7 points by cryptbe 13y ago|0 comments
108.
by cryptbe 13y ago
Two reasons why crypto needs randomness: 1) You need to generate keys that nobody can guess. 2) Much of modern crypto is built based on probabilistic encryption [1]. [1] http://theory.lcs.mit.edu/~cis/pubs/shafi&#x
109.
by cryptbe 13y ago
Cool research. I like how you "connect-the-dots" from the benign-looking MySQL's behaviour to the bad code in Wordpress. This reminds me of http://www.suspekt.org/2008/08/18/mysql-and-sql-column
110.
by cryptbe 13y ago
I didn't say that I trust mail clients. I said mail clients shouldn't accept arbitrary HTML markups and tags in emails. That's a serious problem that needed to be addressed, regardless of Google Scholar being exploited to sen
111.
by cryptbe 13y ago
Wow. Give me a break, please. What the OP reported was a super minor issue, and he's already got what he deserves. His bug allowed him to inject links into verification emails sent by Google Scholar. He claimed that he could inject CSS
112.
by cryptbe 13y ago
> But here, we're talking about IPSEC, not HTTPS/TLS, and the fundamental cryptographic design weakness we're talking about is, I think, Bard's. I could be wrong, though. No, it wasn't Bard's. It's Roga
113.
by cryptbe 13y ago
No, I didn't say that everyone generates their own curves. I meant the security community should generate our own curves. Somebody should email Thomas Pornin.
114.
by cryptbe 13y ago
So maybe we should generate our own curves. I propose something as follows: 1. Locate a public string. A tweet or a quote should suffice. 2. SHA-512 the string to obtain a seed. 3. Use that seed to generate b, and calculate N = #E(Fp) = n *
115.
by cryptbe 13y ago
> He is right about how specific the circumstances are that give rise to Bard's CBC IV attack. Not only that, but BEAST itself was the product of a former NSA cryptologist, now a Wisconsin university math professor; it is vanishingl
116.
by cryptbe 13y ago
Disclaimer: CRIME co-author. It's the same attack. CRIME works for TLS compression, SPDY header compression (yes it broke HTTP/2.0 even before it's called HTTP/2.0), and HTTP gzip response. BREACH was described in slide
117.
by cryptbe 13y ago
If the password hashing APIs asks developers to generate a salt on their own it's neither easy nor safe. I've worked on password hashing recently, and I think the best interfaces should take only a password, and return a hash. Mod
118.
by cryptbe 13y ago
> I've read the quote several times and while it does say that things generally aren't private online it also clearly suggests that you shouldn't be doing things that you don't want other people to find out about which itself suggests t
119.
by cryptbe 13y ago
Hacker News community seem to be interested in crypto, so I guess you guys will enjoy this presentation, which is a summary of web crypto vulnerabilities discovered by Juliano Rizzo and me.
120.
Three years attacking web crypto(docs.google.com)
5 points by cryptbe 13y ago|1 comments

More ›