OLC and Cambridge 10/20/25 support ending

Max, the point is:

Anybody making a logger has to deal with IGC,
if they want to get it "approved".
If "IGC experts" claim that "releasing code
will invalidate approval", well...

PS: Use DOSbox on your PDA for validation ;-)

Dave Nadler wrote:
Anybody making a logger has to deal with IGC,
if they want to get it "approved".
If "IGC experts" claim that "releasing code
will invalidate approval", well...

What, are you serious? Publishing a signature algorithm and the
"public" key will invalidate the IGC logger approval? Is that IGC's
official policy? (Never heard of that rule before) Is that how IGC
thinks cryptography works?

Is that stupidity or willful evil?

PS: Use DOSbox on your PDA for validation ;-)

*shudder*

On Wednesday, December 7, 2011 9:53:45 AM UTC-5, Max Kellermann wrote:
What, are you serious? Publishing a signature algorithm and the
"public" key will invalidate the IGC logger approval? Is that IGC's
official policy? (Never heard of that rule before) Is that how IGC
thinks cryptography works?

Is that stupidity or willful evil?

Max, I didn't say that, I refuted it in the above postings
which you should really read...

Are you going to enlighten us or just wave your hands ?
You are making contradictory statements above...
Thanks !

Dave Nadler wrote:
Max, I didn't say that, I refuted it in the above postings
which you should really read...

Your post seemed to suggest that this is an IGC rule, because (1) you
said you have to deal with IGC rules (2) conjunctive sentence that
discusses an IGC expert thinking this would make the approval invalid.

Strictly speaking, your whole post said nothing, especially the second
sentence that was subjunctive and incomplete (missing the main
sentence). That's why I asked for clarification on what you really
mean. Your response doesn't answer my question.

So how is the fact that you need IGC approval relevant for this whole
discussion and for publishing algorithms + public keys? I don't
understand.

Max

On Wednesday, December 7, 2011 1:57:21 PM UTC-5, Max Kellermann wrote:
...I don't understand.

No kidding. Please read the posts above from TNP and my answers.
Carefully.

Ok, so let me see if I understand this correctly. If the private key
must be held (and protected) within the recorder, then trying to
convert a file that's already outside the recorder would be impossible
since the private key needed for the signature is not accessible. The
real solution would have to be a firmware change in the CAI 10/20/25
itself to enable downloading of an igc format file that is already
signed with the internal private key. It needs to work like the CAI302.

On Wednesday, December 7, 2011 4:31:15 PM UTC-5, Westbender wrote:
Ok, so let me see if I understand this correctly. If the private key
must be held (and protected) within the recorder, then trying to
convert a file that's already outside the recorder would be impossible
since the private key needed for the signature is not accessible.

Not if the file has the signature already computed INSIDE THE LOGGER
prior the data is exported from the logger. This is what is supposed
to happen for an IGC-approved logger.

If it is *not* possible, there's something very fishy about the
existing approval.

Hope that clears it up,
Best Regards, Dave

On Dec 7, 3:43*pm, Dave Nadler wrote:
Not if the file has the signature already computed INSIDE THE LOGGER
prior the data is exported from the logger. This is what is supposed
to happen for an IGC-approved logger.


Doesn't the .cai file have this "signature"?

I'm thinking the security record in the .cai file must have some kind
of checksum information that no longer applies when the file is
converted to igc. The resulting igc file does have "G" records, but I
take they're not valid because the checksum information doesn't match
any more. Or the "G" records are just a faux signature.

Does anyone know the technical details regarding signatures in cai vs.
the converted igc?