You're confusing MR with another primiality test (whose name I don't recall). MR is guaranteed to run in poly time, but it's not guaranteed to give the right answer. There's another test which runs in poly time and gives the right answer, but only if GRH is true. Of course now we have AKS, which runs in poly time and always gives the right answer without relying on any unproven hypothesis.
And in the real world, MR is still your best practical choice.
You just described what every graduate student has to do in order to complete their work.
The key word is "downloaded". This is a discussion of free online access to papers, not one of the distinction between papers and books. Graduate students generally have access to academic libraries; I didn't. Please read more carefully before composing future replies.
Yeah. But how do you know who the good authors are? And how did the citers find the papers in the first place?
The process builds on itself. Given one good author - say, Ron Rivest - you can discover the rest by spidering outwards and using your intelligence. That's mostly what everyone else is doing.
I'm not saying that peer reviewed publications are unnecessary, but I don't want you to overestimate the role they play in being able to find the good stuff.
hell, its pretty rare to see a citation that doesn't refer to a peer reviewed publication
It's unusual, but not vanishingly rare. For example, Andrew Roos's weak keys are cited in many papers about RC4 cryptanalysis, but have been published only online. (Actually I'd love to know what happened to Andrew Roos, he seems to have fallen off the Web)
In my field, cryptography, most recent papers are available online on the author's website. Those that aren't you can often get with a polite email to the author. I went from knowing nothing about the field to publishing cryptanalysis at conference almost entirely through what I've learned from downloaded papers - my "dead tree" cryptographic bookshelf is very minimal. Much of this learning was done without access to an academic library, and would have been impossible in an earlier era.
It's a crime that so many papers are still being published under licences that do not allow their free accessibility on the Web. Scientists of the future will wonder how science was even possible without such access.
The British Army decommision hard drives using an angle grinder. The US use thermite.
That said, for most purposes programs like Eraser will make data recovery so expensive and ineffective that for the data most of us have, nobody will bother. In fact, that's probably true even of less effective measures such as "dd if=/dev/zero of=/dev/hdb".
I also mean it's not "free software", but that term isn't as precisely defined, and some people (IMHO mistakenly) interpret it to mean merely "gratis software". The term "open source" was invented in order to act as a synonym for "free software" in this sense that did not have this ambiguity.
Don't bother telling me about non-open source software to solve this problem, I have open source software that works. The same goes for Qmail.
Though I think the way DJB licenses his gratis software is a shame, I'm not going to take part in the great flamefests about the man - to me, as a cryptographer, he stands as an indisputable contributor of genius to the field.
If the person goes off their meds, you may sometimes have another option: I would assume that pretty much all countries have provision to detain a mentally ill person against their will if their illness is dangerous. In this country the phrasing is "a danger to themselves or others", and it's called "sectioning". Sectioning your friends is about the least fun thing you'll ever do, but it can save their lives.
My closest friend walked out of a mental health ward on a day pass and was never seen again; he almost certainly took his own life that very day, but it's hard to give up hope altogether.
That's not the impression I get from the Web pages. It's generally safe to assume tht if a software project doesn't explain exactly how the crypto is done, they've fucked it up.
I think you're right about the providing too much information thing. I guess I hoped that someone would have solved this specific case specifically for ID3v2, which is my current problem. If someone had been able to say "the X ID3v2 library has code to do this" then that would have solved my current problem even though it's not generic.
But in future I'd write a "general" thing about HTTP as a read-only network filesystem, and then a second "specific" paragraph about why I'm interested.
Think about the actual calls to "read" and "seek" on the filehandle the library does. Now imagine that in the background, you fetch parts of the file only at the moment the application calls "read". You'll see that the application does not "read" every last byte from the file - usually much, much less.
FUSE does exactly this "sorcerer's magic".
Or think about what would happen if the file were served by NFS, rather than by HTTP. Again, only the parts of the file that were needed would be fetched over the network. No magic.
This is an interesting general problem. I'm sorry that so few people seem to have taken the time to understand it before replying. The general approach seems to be "read the first sentence, assume the poster is an idiot, hit reply".
The problems are these:
1) Reading ID3v2 tags on an MP3 file is a complex business. I have no desire to re-implement the libraries that do that, or even to wade deep into the existing codebases, if I can avoid that. And it should be possible to avoid that.
2) Even knowing the size and location of ID3v2 tags is complex. Contrary to popular belief here, those tags can appear at either the beginning or the end of a file, and can be arbitrary size. I already implemented the "fetch some stuff at the beginning and some stuff at the end and feed that to the library" approach, and it sort-of works, but you have to guess the size of the tag. Guess too big, you fetch lots of data unnecessarily. Guess too small, you get breakage or wrong results. By contrast, the libraries that read ID3v2 tags know exactly where and how much to read to glean the appropriate data, and it should be possible to make use of that.
3) I want to read existing data - changing the format of that data is not an option.
So that's why I was suggesting solutions like "FUSE". With FUSE, when the library does a seek and a read, I can arrange for just the relevant portion of the file to be fetched. I don't have to include any knowledge about ID3 in my application - the library does all the work. But the library doesn't have to worry about HTTP byte ranges - FUSE handles that. And the code will always be correct.
The only trouble is that FUSE requires a kernel patch and root privs. The question is, is there a way to do the same trick without those limitations? Or is there a library for reading ID3v2 tags in an object-oriented language that will let me put an efficient back-end for fetching data on request using HTTP byteranges in place of the file?
The best information I've got out of this is that there's a pure-Python implementation of ID3v2 (most implementations appear to be built on top of the C library). This may be hackable to solve my problem.
Those of you who didn't think reading or thinking was necessary before posting - please don't do the next "Ask Slashdot" post the same discourtesy. Thanks.
HTTP can tell you the file size, and with byte ranges you can fetch whichever bits you want.
The *real* problem is this: if I were writing this in Java, and the ID3v2 library were in Java, I could easily provide a seekable InputStream object representing a file which I have a URL for, and the ID3v2 library would read only the parts of the file it needed. It wouldn't have to think about the fact that the file was remote, and I wouldn't have to anticipate what it was going to want to read using the cumbersome and fragile heuristics people have been suggesting here.
However, the best library for these purposes is in C, and it expects to call "seek" on a real, kernel file descriptor. I'm wondering if there's a solution that's as neat in that world.
If there's an implementation of ID3v2 that's entirely written in an OO language and does not use the C library, then the OO language will have almost certainly have the primitives needed to present the URL as one would present a file, for the same neatness of solution.
The paper makes it clear that they're combined using the correct "encrypt-then-authenticate" approach, not just thrown together. That should normally yield a secure channel so I'll be very interested to see what flaws Yoshi Kohno's found with this implementation.
I used to work for a voxel rendering company, Voxar. I developed the fastest software voxel rendering algorithm for opaque surface rendering of its time, around ten years ago. It wasn't used in games - and still isn't - because it'll always be a performance loser for gaming applications for as long as PCs include dedicated polygon hardware.
Comanche Maximum Overkill does not use voxels. I don't know why they chose that word to refer to the heightfields they do use.
I can't find any references that back up the parent's account. Kodiak ripped off some chainmail while the suit was left in his cage, so the live test against Kodiak was cancelled. In all the manned tests, the bears could not be persuaded to attack - the suit looks too alien to be worth it.
Slashdot Mirror
You're confusing MR with another primiality test (whose name I don't recall). MR is guaranteed to run in poly time, but it's not guaranteed to give the right answer. There's another test which runs in poly time and gives the right answer, but only if GRH is true. Of course now we have AKS, which runs in poly time and always gives the right answer without relying on any unproven hypothesis.
And in the real world, MR is still your best practical choice.
The release forms I signed explicitly give permission for the author to publish on their home page. Copyright was assigned to the IACR.
You just described what every graduate student has to do in order to complete their work.
The key word is "downloaded". This is a discussion of free online access to papers, not one of the distinction between papers and books. Graduate students generally have access to academic libraries; I didn't. Please read more carefully before composing future replies.
Yeah. But how do you know who the good authors are? And how did the citers find the papers in the first place?
The process builds on itself. Given one good author - say, Ron Rivest - you can discover the rest by spidering outwards and using your intelligence. That's mostly what everyone else is doing.
I'm not saying that peer reviewed publications are unnecessary, but I don't want you to overestimate the role they play in being able to find the good stuff.
hell, its pretty rare to see a citation that doesn't refer to a peer reviewed publication
It's unusual, but not vanishingly rare. For example, Andrew Roos's weak keys are cited in many papers about RC4 cryptanalysis, but have been published only online. (Actually I'd love to know what happened to Andrew Roos, he seems to have fallen off the Web)
More often by who wrote them and who cites them.
In my field, cryptography, most recent papers are available online on the author's website. Those that aren't you can often get with a polite email to the author. I went from knowing nothing about the field to publishing cryptanalysis at conference almost entirely through what I've learned from downloaded papers - my "dead tree" cryptographic bookshelf is very minimal. Much of this learning was done without access to an academic library, and would have been impossible in an earlier era.
It's a crime that so many papers are still being published under licences that do not allow their free accessibility on the Web. Scientists of the future will wonder how science was even possible without such access.
The British Army decommision hard drives using an angle grinder. The US use thermite.
That said, for most purposes programs like Eraser will make data recovery so expensive and ineffective that for the data most of us have, nobody will bother. In fact, that's probably true even of less effective measures such as "dd if=/dev/zero of=/dev/hdb".
What you can do with it is second only to sendmail
In what way is it behind sendmail? Genuinely curious...
Read at least the first sentence of the Open Source definition, please.
I also mean it's not "free software", but that term isn't as precisely defined, and some people (IMHO mistakenly) interpret it to mean merely "gratis software". The term "open source" was invented in order to act as a synonym for "free software" in this sense that did not have this ambiguity.
Don't bother telling me about non-open source software to solve this problem, I have open source software that works. The same goes for Qmail.
Though I think the way DJB licenses his gratis software is a shame, I'm not going to take part in the great flamefests about the man - to me, as a cryptographer, he stands as an indisputable contributor of genius to the field.
If the person goes off their meds, you may sometimes have another option: I would assume that pretty much all countries have provision to detain a mentally ill person against their will if their illness is dangerous. In this country the phrasing is "a danger to themselves or others", and it's called "sectioning". Sectioning your friends is about the least fun thing you'll ever do, but it can save their lives.
My closest friend walked out of a mental health ward on a day pass and was never seen again; he almost certainly took his own life that very day, but it's hard to give up hope altogether.
That's not the impression I get from the Web pages. It's generally safe to assume tht if a software project doesn't explain exactly how the crypto is done, they've fucked it up.
I think you're right about the providing too much information thing. I guess I hoped that someone would have solved this specific case specifically for ID3v2, which is my current problem. If someone had been able to say "the X ID3v2 library has code to do this" then that would have solved my current problem even though it's not generic.
But in future I'd write a "general" thing about HTTP as a read-only network filesystem, and then a second "specific" paragraph about why I'm interested.
This is completely wrong.
Think about the actual calls to "read" and "seek" on the filehandle the library does. Now imagine that in the background, you fetch parts of the file only at the moment the application calls "read". You'll see that the application does not "read" every last byte from the file - usually much, much less.
FUSE does exactly this "sorcerer's magic".
Or think about what would happen if the file were served by NFS, rather than by HTTP. Again, only the parts of the file that were needed would be fetched over the network. No magic.
What happens when the existing library seeks to near the end of the file and reads a byte?
This is an interesting general problem. I'm sorry that so few people seem to have taken the time to understand it before replying. The general approach seems to be "read the first sentence, assume the poster is an idiot, hit reply".
The problems are these:
1) Reading ID3v2 tags on an MP3 file is a complex business. I have no desire to re-implement the libraries that do that, or even to wade deep into the existing codebases, if I can avoid that. And it should be possible to avoid that.
2) Even knowing the size and location of ID3v2 tags is complex. Contrary to popular belief here, those tags can appear at either the beginning or the end of a file, and can be arbitrary size. I already implemented the "fetch some stuff at the beginning and some stuff at the end and feed that to the library" approach, and it sort-of works, but you have to guess the size of the tag. Guess too big, you fetch lots of data unnecessarily. Guess too small, you get breakage or wrong results. By contrast, the libraries that read ID3v2 tags know exactly where and how much to read to glean the appropriate data, and it should be possible to make use of that.
3) I want to read existing data - changing the format of that data is not an option.
So that's why I was suggesting solutions like "FUSE". With FUSE, when the library does a seek and a read, I can arrange for just the relevant portion of the file to be fetched. I don't have to include any knowledge about ID3 in my application - the library does all the work. But the library doesn't have to worry about HTTP byte ranges - FUSE handles that. And the code will always be correct.
The only trouble is that FUSE requires a kernel patch and root privs. The question is, is there a way to do the same trick without those limitations? Or is there a library for reading ID3v2 tags in an object-oriented language that will let me put an efficient back-end for fetching data on request using HTTP byteranges in place of the file?
The best information I've got out of this is that there's a pure-Python implementation of ID3v2 (most implementations appear to be built on top of the C library). This may be hackable to solve my problem.
Those of you who didn't think reading or thinking was necessary before posting - please don't do the next "Ask Slashdot" post the same discourtesy. Thanks.
Thank you - you appear to be the first person to have understood my request. Was I that unclear?
CDDB is a completely different file format from ID3v2.
HTTP can tell you the file size, and with byte ranges you can fetch whichever bits you want.
The *real* problem is this: if I were writing this in Java, and the ID3v2 library were in Java, I could easily provide a seekable InputStream object representing a file which I have a URL for, and the ID3v2 library would read only the parts of the file it needed. It wouldn't have to think about the fact that the file was remote, and I wouldn't have to anticipate what it was going to want to read using the cumbersome and fragile heuristics people have been suggesting here.
However, the best library for these purposes is in C, and it expects to call "seek" on a real, kernel file descriptor. I'm wondering if there's a solution that's as neat in that world.
If there's an implementation of ID3v2 that's entirely written in an OO language and does not use the C library, then the OO language will have almost certainly have the primitives needed to present the URL as one would present a file, for the same neatness of solution.
mcrypt also appears to lack integrity protection.
To be honest, GPG the only option likely to be secure.
"aespipe" has far more serious mistakes than WinZip: the IV is not generated properly and there is no integrity protection at all.
There are also "key collision" attacks on the container itself.
The paper makes it clear that they're combined using the correct "encrypt-then-authenticate" approach, not just thrown together. That should normally yield a secure channel so I'll be very interested to see what flaws Yoshi Kohno's found with this implementation.
I used to work for a voxel rendering company, Voxar. I developed the fastest software voxel rendering algorithm for opaque surface rendering of its time, around ten years ago. It wasn't used in games - and still isn't - because it'll always be a performance loser for gaming applications for as long as PCs include dedicated polygon hardware.
Comanche Maximum Overkill does not use voxels. I don't know why they chose that word to refer to the heightfields they do use.
I can't find any references that back up the parent's account. Kodiak ripped off some chainmail while the suit was left in his cage, so the live test against Kodiak was cancelled. In all the manned tests, the bears could not be persuaded to attack - the suit looks too alien to be worth it.