sdevlin

9 ms·

151.
by sdevlin 13y ago
Python has a decimal package in stdlib. It provides an arbitrary-precision floating point type. The performance will obviously be worse than with floats, but I doubt it matters in an intro programming class. The only real drawback is that t
152.
by sdevlin 13y ago
Then what's the point?
153.
by sdevlin 13y ago
> "Nobody is going to die." This isn't accurate, e.g. http://cryptome.org/2012/07/chile-comments.htm . Bad crypto is actually much more dangerous than a single rogue dentist.
154.
by sdevlin 13y ago
> However, it is not a matter of debate that the RSA backdoor of BSAFE was and is not open merely to the NSA. It is an objective fact that anyone can take advantage of a backdoor like this. This is not accurate. You need to know the priv
155.
by sdevlin 13y ago
That's an old-school C function declaration. Note that the function return type are parameter types are implicitly int. nE is then explicitly declared to be a char pointer pointer.
156.
by sdevlin 13y ago
More importantly, all encryption keys are either fixed or stored directly alongside ciphertext. The cryptography in this system seems to be 100% cosmetic, so I'm not sure things like ECB mode or absence of MAC really matter. EDITED for
157.
by sdevlin 13y ago
Sorry, I'm afraid my original post wasn't very clear. I was describing potential problems with Moxie's intentionally weak protocol, not with Telegram. The hash in question is MD2 used to reduce the 32-byte random secret to a
158.
by sdevlin 13y ago
You're right and I'm wrong. Mea culpa. I dashed these off quickly. Unfortunately I can't edit anymore, so the erroneous #5 will have to stay there. The main bad thing here is the null padding (covered in #4). This gives the a
159.
by sdevlin 13y ago
To be clear, I'm describing problems with Moxie's hypothetical broken protocol, not with Telegram. Telegram does not (as far as I know) use Dual_EC_DRBG.
160.
by sdevlin 13y ago
This is true, but you could easily respond by increasing the RSA key size. This would make the protocol Telegram-secure without meaningfully improving its actual security profile in any way.
161.
by sdevlin 13y ago
Also no side channel observations.
162.
by sdevlin 13y ago
For reference, here's a list (probably incomplete? (EDIT: and feel free to add!)) of ways this protocol is broken: 1. There's no authentication at any point. The whole thing is trivially MITM-able. 2. The RNG is Dual_EC_DRBG
163.
by sdevlin 13y ago
Your analysis is correct. Their terms and conditions rule out just about every form of attack.
164.
by sdevlin 13y ago
This is really chickenshit, which is completely in line with everything else these guys have said or done. Just so we're clear, this rules out: * Chosen plaintext attacks * Chosen ciphertext attacks * Adaptive chosen ciphertext
165.
by sdevlin 13y ago
Nit: "Paterson", not "Peterson".
166.
by sdevlin 13y ago
Matasano - New York City, Chicago, San Francisco Bay Area We test software for vulnerabilities. Sorry, that's too clinical - the reality is that we torture and flay software, twisting it to serve our nefarious ends. If that sounds like
167.
by sdevlin 13y ago
If 2048-bit RSA is vulnerable, then RSA is probably toast.
168.
by sdevlin 13y ago
> Is the Thoreau in the Thoreau 2.0 picture wearing Google Glass glasses? As I understand Thoreau, he would today look exactly as he looked then. He surrounded himself with vegetables, beans, trees, critters, and such. Maybe a t-shirt or
169.
by sdevlin 13y ago
What problem does a predictable nonce cause?
170.
by sdevlin 13y ago
You put quotes around several phrases that are not used in the featured article. I suspect you do not understand this punctuation mark.
171.
by sdevlin 13y ago
Suite B does not contain RSA. EDIT: To your latter point, some people would consider this to be a telling fact.
172.
by sdevlin 13y ago
I guess that's true, but in practice XSS is a much bigger threat to your application than someone MITM'ing an HTTPS connection to Google's (or whomever's) CDN.
173.
by sdevlin 13y ago
How would this protect you against a malicious server?
174.
by sdevlin 13y ago
Well, let me explain my thinking. Suppose we sign https://server.com/sjcl.js . That resource is now tamper-proof in the event that server.com is compromised. But what about the rest of the application HTML/js? For examp
175.
by sdevlin 13y ago
If you don't trust the server, you're screwed anyway.
176.
by sdevlin 13y ago
A few reasons. The overarching problem is that you don't really get any feedback about whether what you're doing is right or wrong. For example, no cryptographer would use RSA like that, but that's not obvious just from study
177.
by sdevlin 13y ago
Your point is well taken, but I think it has value. Compile-time error checking is useful because it gives you flexibility to make changes in a big program. It's kind of like a big suite of automatic tests that make sure all the parts
178.
by sdevlin 13y ago
I sometimes find myself torn between dynamic typing (great for rapid prototyping) and static typing (great for tooling and compile-time error checks). I'm a big fan of TypeScript's approach, which gives you the best of both worlds
179.
by sdevlin 13y ago
Changing the CSRF token with each request would work, but you also risk frustrating your users this way. If you have more than one tab open on the same web application, you could only submit a form successfully from the "freshest"
180.
by sdevlin 13y ago
> Is there any general way of preventing this kind of attacks? Disabling compression is a 100%-effective countermeasure for compression oracle attacks. > Also, why does the site http://breachattack.com/ says that &quo

More ›