Why can't something like OpenSSL be used for signing? This shouldn't really take that long to integrate...
OpenSSL. Possibly, but we still need to do the work. We're "a bit" busy. Actually, before I saw your post, I clarified my previous post to emphasise that we would want this functionality in the library so an emulator just has to say "who issued it and does the signature correct" - to make it far more likely they would do so.
Also, couldn't IPF's be invalidated by adding the hash to a "blacklist" of sorts? Or removing it from the official list? Of course, this would only be needed for officially signed IPF's.
"The hashes would indicate it was from us" ... that's a bit overworked. Public-private key crypto would be so much more efficient here ... instead of a hash per IPF, only a public key would be needed. But the IPFs themselves would need to hold signature info — which I hope is part of the current IPF standard, since I do think it should be.
That's not to say we have thought about it much beyond this. As I said, we've not managed to get time to look into it.
But it's useful to know why you think that should or shouldn't be the case, on the basis of what's best for the format overall, it's acceptance and it's practical use as a preservation medium, not just any particular personal preference.
It was originally created for the universal HxC floppy emulator: http://hxc2001.free.fr/floppy_drive_emulator/
Software is also provided to convert from all popular file formats, including IPF, to HFE format.
What are your plans regarding this stuff?
IPF is efficient, and can change its context without changing the content, ie not medium specific; be it software emulation, hardware emulation, or actually writing to the real media or a different media type. It can also change certain parameters run-time to adopt to the properties of the target media.
IPF file data content can also be compared by design, regardless of context or context like data such as gap information; ie you can compare two IPFs and can tell by absolute certainty whether they are duplicates or not, even though your dump files could be very different due to other reasons.
No other preservation format was ever designed that supports all of these things.
Besides other things: HFE can not store the density information (=variation) present in many protections. This means such data gets lost during conversion from IPF to HFE. I am also sure weak (flakey) bits are am issue.
Jeff has made it clear several times that the format was designed to have something that fits the HxC SD card edition.
IPF should have a section for metadata. In this metadata, a signature field should exist, and even a public key field. This metadata area should be extensible.
Such metadata would be used to verify the validity of an IPF.
This isn't a part of the actual IPF data, just metadata. Similar to EXIF tags in JPEG, or ID3 tags in MP3.
At least that's how I'd do it