×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Comments

top

Retired SCOTUS Justice Wants To 'Fix' the Second Amendment

blueg3 Re:Actually the correct fix is far fewer words (1570 comments)

Why do you want to add a grammatical error to the Constitution? It's apparently hard enough to interpret as it is.

2 days ago
top

Intuit, Maker of Turbotax, Lobbies Against Simplified Tax Filings

blueg3 Re:Lobbying aside (415 comments)

It doesn't need to be better than the market. It needs to be better than the market minus capital gains taxes and broker fees.

Depending on what you're using the money for, capital gains taxes may be zero. And 10% is worse than the index funds after fees -- this year.

2 days ago
top

OpenBSD Team Cleaning Up OpenSSL

blueg3 Re:What about a re-implementation... (288 comments)

Real security is very hard. But really, real [lots of things in programming] are very hard if you want them done right. It's certainly possible for a higher-level language to expose the capabilities necessary to do things right. But if they don't, then it's a bad situation.

3 days ago
top

Intuit, Maker of Turbotax, Lobbies Against Simplified Tax Filings

blueg3 Re:Lobbying aside (415 comments)

10% wasn't better than the market last year. (It is, however, a very solid rate of return.)

3 days ago
top

OpenBSD Team Cleaning Up OpenSSL

blueg3 Re:What about a re-implementation... (288 comments)

...you can receive that passphrase into a char array on the stack, use it, and zero it out immediately. Poof, gone in microseconds.

Only if you've set that part of your stack to locked. Otherwise it could get paged out to disk. Thanks to the fun of timing on computers, the amount of actual time that passes between "receive [into memory]" and "zero out" is arbitrarily long.

3 days ago
top

OpenBSD Team Cleaning Up OpenSSL

blueg3 Re:What about a re-implementation... (288 comments)

So if C is so bad why should we trust the languages that are implemented in it? You do realize that most of these "safe" languages are written in C, right?

I'm just going to link to a previous comment where I answered the same question.

TLDR: Languages aren't "written in" anything, and the language the compiler is written in has no bearing on the capabilities of the language it compiles. (We're all Turing complete here.)

3 days ago
top

Heartbleed Coder: Bug In OpenSSL Was an Honest Mistake

blueg3 Re:It's not just the implementation (445 comments)

For one, you need to be able to correlate your requests with the other party's responses in a way that is non-replayable (regardless of the encryption used).

The payload is of variable length so that heartbeats can be used for path MTU discovery.

Just because someone "sees no reason" for a design decision doesn't mean there is no reason.

The heartbeat spec isn't necessarily a great design, but it's by no means the problem. If you can't implement what is essentially ping that passes two variable length data fields, what hope do you have of being able to implement anything useful?

about a week ago
top

Heartbleed Coder: Bug In OpenSSL Was an Honest Mistake

blueg3 Re:for a library... (445 comments)

And what languages are these languages themselves written in?

Languages aren't written in anything. (Though, the specification for a language could be written in English, for instance.) Compilers and interpreters are written in a language.

and if those languages are dangerous to directly write apps in, then surely they must be equally dangerous to write the compilers and platforms on which your non-VM language runs.

A program isn't run by a compiler, it's compiled by a compiler. There's a pretty significant difference.

There's also a significant difference between writing an application in C and writing an application in a language that is compiled by a compiler written in C. For one, the compiler has a much smaller attack surface. There is a lot less code in the compiler than there is in the set of applications written in that language. For another, vulnerabilities aren't magically transitive like that. Imagine a language, M, that is just like C, but it is impossible to create a buffer overrun. The M compiler is written in C. It contains a buffer overrun bug. That doesn't magically make M source code compiled with this compiler also contain a buffer overrun. To say it another way: the features of the language the compiler is written in don't really matter for the security of a compiled application, it's the quality of the implementation of the compiler -- the compiler needs to produce a binary that actually has the properties of the language it's compiling for.

At some point you're working with something written in C, C++ or assembler

No, you're not. Traditionally, a compiler is written in the same language that it compiles: so a C++ compiler is written in C++ and a Forth compiler is written in Forth. (Realistically, most are now written in C as a component of GCC.)

about a week ago
top

Heartbleed Coder: Bug In OpenSSL Was an Honest Mistake

blueg3 Re:Bigger problem: stupid 'optimizations' (445 comments)

...then there is a real world cost to not optimizing this code.

Turns out there's a real-world cost to optimizing it, too!

about a week ago
top

Heartbleed Coder: Bug In OpenSSL Was an Honest Mistake

blueg3 Re:for a library... (445 comments)

There are languages that are neither C nor run on a virtual machine.

about a week ago
top

Heartbleed Coder: Bug In OpenSSL Was an Honest Mistake

blueg3 Re:It's not just the implementation (445 comments)

As others have indicated, the primary stated use of heartbeat is for DTLS, which is not over TCP.

The payload length is not actually superfluous. The packet has an arbitrary amount of both payload and padding, of which only the payload is echoed to the sender. Roughly: { uint16 payload_len; char payload[]; char padding[]; } The intent of payload_len is to tell you which of the bytes following it are payload rather than padding. Of course, you need to check that it's less than the remaining data in the packet. (Per the spec, at least 16 less -- at least 16 bytes of random padding are required.)

about a week ago
top

Elite Violinists Can't Distinguish Between a Stradivarius and a Modern Violin

blueg3 Re:Modern audiophiles are no different. (469 comments)

He didn't say they weren't different. He said people think that vinyl is "more genuine" or "more accurate" than digital. Genuine is a weasel word -- it's ill-defined. (Probably the most reasonable definition here is "closest to how the creator of the music intended for you to hear it". But, I digress. It's hard to measure.) Vinyl is certainly less accurate than a good digital representation.

It can be different, though, because it introduces flaws that the digital representation doesn't have. Maybe those flaws make the music "better" in some sense, but not "more accurate".

about two weeks ago
top

Department of Transportation Makes Rear View Cameras Mandatory

blueg3 Re:13 deaths? (518 comments)

You don't. Your field of vision through the back window is tiny compared to the field of vision of the camera.

I thought they were a stupid gimmick until I got a car with one. Now I curse every time I drive a car that doesn't have one, because backing up is a lot harder.

about two weeks ago
top

Dropbox's New Policy of Scanning Files For DMCA Issues

blueg3 Re:Huh? (243 comments)

He wasn't making an analogy between how you find a hash collision and how you win the lottery -- only comparing the odds.

Dropbox uses SHA-256 hashes. I'm assuming this is what they use for this feature, since it's what they use internally for file identification and deduplication. They actually hash 2 MB file chunks, which means that any file more than 2 MB produces multiple hashes (one per chunk, naturally).

The "many chances of winning" you're referring to here is the birthday collision problem. A good, rough approximation is that for an N-bit hash, while the number of different hashes is 2^N, the number you can generate before risking a collision is about 2^(N/2). So, with SHA-256, we run no significant risk of collision until we've generated around 2^128 ~= 10^38 hashes.

The total amount of data stored worldwide is on the order of 1 ZB. That's room enough for about 10^15 2-MB chunks. Of course, some of our files might be smaller than this 2 MB chunk size, enabling us to be more efficient with storage. We might be able to get somewhere around 10^20 different files in there.

That's a strange and untenable use of all of the world's storage, and it still puts us about 18 orders of magnitude short of being able to risk a SHA-256 collision. If you had this giant set of a ton of different files, the probability of a collision existing is about 1 in 10^37.

So, short of a flaw in SHA-256, you can assume that a hash collision will never happen. We know of no such flaws. (If we do, it will almost certainly be the case that the collision only occurs because one of the two files was specifically manipulated to produce the collision.)

On the other hand, the odds of winning the lottery are rarely worse than 1 in 10^9.

about three weeks ago
top

Dropbox's New Policy of Scanning Files For DMCA Issues

blueg3 Re:Huh? (243 comments)

But computing a hash-value IS going through your files.

In the same sense that receiving them from you, storing them, or transmitting them to others (at your request) is "going through" your files.

Dropbox already uses SHA-256 hashes internally for file identification and deduplication. So it's been hashing all of your data this whole time.

about three weeks ago
top

eBay Japan Passwords Revealed As Username+123456

blueg3 Re:Almost-best practices (80 comments)

One site I've worked on uses the user ID, username, join date/time, and a secret per-site string as the salt for the password. User IDs are sequential and can be sort of guessed from the join date, but I'm under the impression that there's enough entropy in the minutes and seconds of the join date/time, and the secret per-site string keeps the lookup table from applying to more than one site.

The function of salt is to make password cracking efforts more difficult when the attacker has access to the site's password database. So, predictability is not as important, since all the listed information is available to the attacker anyway. (Similarly, the salts are available to the attacker.) That doesn't look like much entropy, though. Really, storing an extra column of random, per-user salts in a database is not particularly hard and has tangible (though not magical) benefits.

The bad guys can already do that by trying to register an account with that username or by trying to send a private message to that username.

Yeah. IMO, usernames should never be relied on for security. Just assume an attacker can determine what usernames are taken and which aren't, and further assume that an attacker with a particular target can figure out the username for that target. (Unless pseudonymity is a key design aspect of your system.)

about three weeks ago
top

eBay Japan Passwords Revealed As Username+123456

blueg3 Re:Hey (80 comments)

They're not talking about a fixed value that's different from "+123456". They're talking about using a different, random value for each user. That is more secure. (There's still plenty of security problems, but it's better than every user's password being completely predictable.)

Of course, if you're bothering to store a different random value for each user, there's no reason to include their username in the password. Just store a long random password for each user. (That's still not great security -- never mind that the password is exposed in cleartext and transmitted over HTTP -- because a user can't change a compromised password.)

about three weeks ago
top

eBay Japan Passwords Revealed As Username+123456

blueg3 Not salt (80 comments)

It looks from the video that the password is simply the username concatenated with a global string, "123456".

That's not salt. That's not what the word means. A salt is data that is not part of the password but is combined with the password when hashed. The client side never sees salt.

So all these discussions of salt are not at all relevant.

This is fundamentally a case of hard-coded credentials, which is more stupid than a non-random salt. (Also, really, transmitting credentials over HTTP?)

about three weeks ago
top

MtGox Finds 200,000 Bitcoins In Old Wallet

blueg3 Re:Possible (227 comments)

...is it possible that MtGox is just that incompetent?

Absolutely. It's just a question of whether their incompetence happened to be the cause here.

about a month ago

Submissions

blueg3 hasn't submitted any stories.

Journals

blueg3 has no journal entries.

Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...