IPF and Openness

All news about KryoFlux go here.
balrog
Posts: 17
Joined: Sat Feb 12, 2011 2:57 pm

Re: IPF and Openness

Post by balrog » Sun Feb 13, 2011 1:47 am

Whatever you do, please don't hardcode hashes. I'd rather provide an XML file or such with the hashes. This way if it's found that rips were done badly, they can be invalidated later.

Why can't something like OpenSSL be used for signing? This shouldn't really take that long to integrate...

User avatar
karadoc
Posts: 124
Joined: Sun Oct 31, 2010 9:12 pm

Re: IPF and Openness

Post by karadoc » Sun Feb 13, 2011 1:58 am

The hashes would indicate it was from us, that is all. I can't see why people would want to edit them, and it saves having a file having to be placed somewhere. The only other way is to re-issue all the current IPF's... but that would be annoying for everyone, not least that there are 3600 of them.

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.

User avatar
IFW
Posts: 2634
Joined: Mon Nov 08, 2010 2:42 pm

Re: IPF and Openness

Post by IFW » Sun Feb 13, 2011 2:10 am

The library has no dependencies (licensing or technical/other libraries), apart from some minor issues, that were very easy to overcome when it was ported to Linux, Mac and AmigaOS.

balrog
Posts: 17
Joined: Sat Feb 12, 2011 2:57 pm

Re: IPF and Openness

Post by balrog » Sun Feb 13, 2011 2:38 am

Unfortunately writing a good (read: no significant bugs) public-private key implementation from scratch is pretty tedious work. Why not use OpenSSL as a compile time option? That way if someone doesn't want the external dependency, they can leave out the crypto features (until it's reimplemented internally).

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.

User avatar
karadoc
Posts: 124
Joined: Sun Oct 31, 2010 9:12 pm

Re: IPF and Openness

Post by karadoc » Sun Feb 13, 2011 9:28 am

I'm not sure I understand quite what you mean. The hard coded hashes in the library would only be for the current set of IPF files that do not have a signature The library call to verify origin would check against that list if no signature was present in the IPF itself (and so transparent to library users).

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.

User avatar
Interceptor
Posts: 58
Joined: Wed Oct 06, 2010 10:17 am

IPF and Openness

Post by Interceptor » Sun Feb 13, 2011 10:01 am

Quite a few people say 'you should do this and use this and don't do this and I'd prefer this'

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.

phi2x
Posts: 3
Joined: Sat Feb 12, 2011 12:15 pm

Re: IPF and Openness

Post by phi2x » Sun Feb 13, 2011 12:12 pm

It's interesting to note that there is another file preservation format that is gaining grounds these days: the HFE file format.
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?

User avatar
IFW
Posts: 2634
Joined: Mon Nov 08, 2010 2:42 pm

Re: IPF and Openness

Post by IFW » Sun Feb 13, 2011 12:32 pm

Nothing. The format you mentioned is timing and pulse information, not content with context.

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.

User avatar
mr.vince
Posts: 1870
Joined: Tue Oct 05, 2010 5:48 pm

IPF and Openness

Post by mr.vince » Sun Feb 13, 2011 9:01 pm

Funny how things become a preservation format over night.

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.

balrog
Posts: 17
Joined: Sat Feb 12, 2011 2:57 pm

Re: IPF and Openness

Post by balrog » Sun Feb 13, 2011 9:03 pm

What I meant is as follows:

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 :)

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests