no, the AES implementation is fine. the vulnerability is the ability to detect the padding exception in the block cypher.
you don't need to see the padding exception, you just need to know that it occurred. you can do that via a variety of means, not limited to http status codes, timing, etc...
well, smartass, he did miss off the units, didn't he?
E = m c^2
see the units there? no? right, there aren't any.
Sure, the dimensions are implied by those terms, but is E measured in Joules, Calories, eV, tons of TNT?
You could say that that the scales don't matter, you just pick the value of c that balances the equation. But that's a circular argument, the way to find c is to rearrange the above equation. You need to look elsewhere in the paper for Einstein's units (CGS).
actually, i omitted the units because 1) slashdot doesn't support superscript, and 2) there's already an 'm' in the equation and having two different 'm's in the same equation gets noisy.
if you get to san francisco, go to the exploratorium and check out the coriolis fountain it's one of the best exhibits there (although my favorite is the bubble chamber).
it is the sole remaining species in the Genus Ornithorhynchus and the Family Ornithorhynchidae. along with the echidnas (do they need explaining, too?) they make up the Order Monotremata, the egg-laying, web-footed, electrolocating mammals. they evolved, just like the rest of us.
if there had only been one remaining species of marsupial, would they need explaining?
public static void Main (string [] args)
{
var re = new Regex (args [0]);
var lines = File.ReadAllLines (args [1]);
Console.WriteLine (lines.Grep (re));
}
if you're not communicating type information via a language's type system, then you're communicating it via some other means: documentation, convention, comments, etc... if you have a small amount of code and few developers then this communication is reasonably easy. but it doesn't scale to large teams or large codebases.
regardless of what mechanism you're using, you still require some means of verifying that your types line up. there's a tool for automating this process - it's called a compiler.
Value types, these are structs that are not wrapped in an object Don't see the benefit of being more procedural in an object oriented language, but good for you I suppose
VM-level support for generics Not missing it. Code level generally catches 99.99999% of any generic-type problems that I've ever run into
these two alone are IMO the biggest differences between the two: -.NET's collections are (mostly) orthogonal with respect to arrays, builtin & reference types (Array<T> implements IList<T>, for all T) - Java's are not, resulting in the whole int/Integer mess, Arrays.toList() and other crap.
yeah, that's my point. they're not file descriptors (though that's what they're called); they're descriptors of things that share some API functions with file descriptors.
windows has exactly the same kind of API abstraction, but instead of calling them 'file descriptors', windows calls them 'object handles'.
they can refer to:
Access tokens
Change notifications
Communications devices
Console inputs
Console screen buffers
Desktops
Events
Event logs
Files
File mappings
Heaps
Jobs
Mailslots
Modules
Mutexes
Pipes
Processes
Semaphores
Sockets
Threads
Timers
Timer queues
Timer-queue timers
Update resources
Window stations
the APIs are not completely orthogonal, for example to close a socket you call 'closesocket()' instead of 'CloseHandle()'
not really. the only things in unix that are file handles are handles to open files. however, there are many things that are called file handles, which are, in fact, handles to something completely different.
really the only difference between windows and unix in this regard is that windows calls them "object handles" instead of "file handles" in recognition of this fact. the idea that you can have a polymorphic API that acts on abstract items is the same.
it's probably a little better than the alternative: the 'high-velocity exploding lead shrapnel to the head'-ray. that inflicts pain, too. but it's a little harder to turn off.
Slashdot Mirror
no, the AES implementation is fine. the vulnerability is the ability to detect the padding exception in the block cypher.
you don't need to see the padding exception, you just need to know that it occurred. you can do that via a variety of means, not limited to http status codes, timing, etc...
all you need is a 1-bit difference between the response for the padding error case and the non-error case.
once you have that bit you have the machine key. once you have the machine key you have all the sites on that machine that share that machine key.
no, i'm just suggesting that your pedantic implication that someone isn't smart if they omit units applies to Einstein in this case.
well, smartass, he did miss off the units, didn't he?
E = m c^2
see the units there? no? right, there aren't any.
Sure, the dimensions are implied by those terms, but is E measured in Joules, Calories, eV, tons of TNT?
You could say that that the scales don't matter, you just pick the value of c that balances the equation. But that's a circular argument, the way to find c is to rearrange the above equation. You need to look elsewhere in the paper for Einstein's units (CGS).
actually, i omitted the units because 1) slashdot doesn't support superscript, and 2) there's already an 'm' in the equation and having two different 'm's in the same equation gets noisy.
get them to answer in terms of the constants given in the question. don't give the values of the constants. don't let them substitute values for them.
Einstein didn't write E=m * 89875517873681764, did he?
if you get to san francisco, go to the exploratorium and check out the coriolis fountain it's one of the best exhibits there (although my favorite is the bubble chamber).
i was referring less to the fuzzy exterior and more to the pouch, the 3 vaginas and the 2 penises.
nature can get pretty freaking weird if it wants. it doesn't need any explanation, though - it just happened.
No, the echidnas (the other surviving family in Order Monotremata) are not venomous.
Besides, the Platypus is venomous, not poisonous.
no, not all the Monotremata are venomous or duck-billed.
that's nothing you should see my iPhone 3G after installing iOS4.
something like this:
http://www.youtube.com/watch?v=Pdk2cJpSXLg
why does the platypus always need explaining?
it is the sole remaining species in the Genus Ornithorhynchus and the Family Ornithorhynchidae. along with the echidnas (do they need explaining, too?) they make up the Order Monotremata, the egg-laying, web-footed, electrolocating mammals. they evolved, just like the rest of us.
if there had only been one remaining species of marsupial, would they need explaining?
oh man, that's the best argument i've ever heard. if i knew you were going to say that i wouldn't have even bothered.
my point was that there are typed languages that are just as expressive, but that come with a robust type system.
i guarantee you i save more time not having to write test to validate the type-correctness of my code.
isn't that what compaq did to IBM way back when? seem perfectly legit to me.
wait, languages that are syntactically different but that are able to say the same thing, are the same language??
does that mean English and French are the same language?
yeah, except they forgot to overload '==', doh.
c# is quite expressive:
public static string Grep (this IEnumerable @this, Regex re)
{
return @this.Select (l => re.IsMatch (l)).Join ('\n');
}
public static void Main (string [] args)
{
var re = new Regex (args [0]);
var lines = File.ReadAllLines (args [1]);
Console.WriteLine (lines.Grep (re));
}
that's 100% statically typed.
if you're not communicating type information via a language's type system, then you're communicating it via some other means: documentation, convention, comments, etc... if you have a small amount of code and few developers then this communication is reasonably easy. but it doesn't scale to large teams or large codebases.
regardless of what mechanism you're using, you still require some means of verifying that your types line up. there's a tool for automating this process - it's called a compiler.
get one.
these two alone are IMO the biggest differences between the two: .NET's collections are (mostly) orthogonal with respect to arrays, builtin & reference types (Array<T> implements IList<T>, for all T)
-
- Java's are not, resulting in the whole int/Integer mess, Arrays.toList() and other crap.
... he doesn't fart.
you can colo in the exchange (for a price). moving the profits does not need to be fast...
LOL, I used to have windows on my D: drive (in d:\winnt), and my C: drive was my CD-ROM.
i can't tell you how many times my CD tray would open followed shortly by some poorly written piece of crap crashing.
yeah, that's my point. they're not file descriptors (though that's what they're called); they're descriptors of things that share some API functions with file descriptors.
windows has exactly the same kind of API abstraction, but instead of calling them 'file descriptors', windows calls them 'object handles'.
they can refer to:
the APIs are not completely orthogonal, for example to close a socket you call 'closesocket()' instead of 'CloseHandle()'
not really. the only things in unix that are file handles are handles to open files. however, there are many things that are called file handles, which are, in fact, handles to something completely different.
really the only difference between windows and unix in this regard is that windows calls them "object handles" instead of "file handles" in recognition of this fact. the idea that you can have a polymorphic API that acts on abstract items is the same.
having seen Sun's sources to the win32 part of the JRE, I'm not surprised. not the worst windows code I've ever seen, but close.
it's probably a little better than the alternative: the 'high-velocity exploding lead shrapnel to the head'-ray. that inflicts pain, too. but it's a little harder to turn off.