Here's how I think encrypting would work with ABC/HR, using public/secret keys:

There would be a new option from within ABC/HR to randomly generate a key pair. The administrator would distribute the public key and keep the secret key. A key pair would be randomly generated from user input.

The public key would be required to decrypt the config file (which means that the config file can't really be secure), and the secret key would be required to decrypt the results file.

ABC/Hr would have a menu option to encrypt the config file, once it has been edited by the test administrator. There would be another menu item to load an encrypted config file, and the program would ask for the location of the public key if it's selected, so that it can decrypt the config file. Note that it would be possible for the user to write a utility program to decrypt the config file for himself if he really wanted to, using the supplied public key.

If an encrypted config file is loaded, the setup menu would be blanked out, so that the user cannot see what filenames or time alignments are being used. One way to hide the codecs or options being used, for example, would be to generate or supply more files than are actually used by the test.

Inside the config file would be a new option to encode the results file, along with the path to the public key. Encryption would occur before results get written to file (an unencrypted results file would never be generated). There would be a menu option from the program to decrypt the results file, and it would ask for the path to the secret key.

It would be possible to have only an encrypted config file, or only an encrypted results file, or both, or neither.

What do people think? Is it worthwhile? Would this be difficult to implement?

ff123

splendid way to accurately test crucial things and to even more secure the outcome of each test.
I vote for this. I don't think it would be all that difficult to implement.

I can't think of any way how this could be really secure - since we have the source code of ABC/HR and the encryption takes place within the source.

On the other hand I don't think someone would spend some time on modifiying your source or write an additional tool just to put statistical noise in some listening test. By now it's just too tempting: Open the results file with your favorite editor and boost your favorite's codec score.

So I guess putting encryption would prevent 99% of testers from modfying the results file and would be quite some enhancement. But always keep in mind that this is no way secure.

I'd like to see encryption in ABC/HR or WinABX. Cheating is a risk we can't exclue, especially on a public and multiformat test. Unfortunately, I can't help any developer :/

difficult? , well, you tell us, iirc you are the developer

worthwhile, yes

I believe it could be made totally secure if, for example, the program talked to a server over SSL, and the client (ABC/hr) was authenticated. However, that is not an option.

The issue is that the listener could, if sufficiently motivated, generate a fake encrypted results file using the public key. So there is no way to prevent that type of cheating in the scheme I'm thinking about. But it is possible to prevent listeners from looking at legitimately generated results.

ff123

I really hope that this is implemented. Imo very important feature.

openssl is fully open source, and i think its help making it stronger and stronger, in the PKI domain
so imho the availability of the source code isn't a problem

Oops. Looks like I may not be able to find an appropriate opensource public-key encryption library:

http://www.thefreecountry.com/sourcecode/e...ncryption.shtml

There is GNUPG, but this is distributed under the General Public License. ABC/Hr is LGPL, and I don't really want to change that.

ff123

Edit: as for SSL, I really didn't want to force ABC/Hr to talk to a server.

Edit2:

Looks like there is opensource public key encryption in crypto++

http://www.eskimo.com/~weidai/cryptlib.html

Ack, looks like this might be some work.

Edit3:

D'oh! I guess OpenSSL would work, as it is applicable to general public key encryption as well as over a secure connection.

I wonder if it would be easier to just use a symmetric key. Nothing here is really secure anyway. The listener could decrypt the config file, since he would have access to ABC/HR's secret key.

Also, the listener could also find out his results if he really wanted to by loading up ABC/HR into a debugger (the source code is available), and then watching what happens in the debugger.

So if that's the case, why not just have a symmetric key built into the source code, which is acknowledged to be non-secure, but would prevent the easiest form of cheating, which is to modify the results file. It would also prevent another, subtler form of cheating, and that is to look at the results file and deciding what to do based on that.

With this non-secure scheme, the test admin would be instructed to enter an admin password, which would be put into the config file before it is encrypted.

ABC/HR would decrypt the config file, and store the admin password in memory.

When the encrypted results file is written, ABC/Hr would again write this password into the file.

When the test admin want to view the results file, he would instruct ABC/Hr to decrypt the file, which it would, but then the program would not display the results until the admin has entered the same password it finds in the results file.

This seems to me like a simpler scheme, as no external files are involved, and probably symmetric keys are easier to work with.

ff123

Public key encryption would be more useful:
you could put a public key in config files (which would encrypt the results - undecryptable)
encrypted with another secret key contained within ABC/HR.

/EDIT\ You might want to use more compact (and harder to read) format for config files. \EDIT/

Public key encryption WOULD be useful, but will never be really secure. As somebody else mentioned, they can use the same key to encrypt fake results. Using a symmetric key would only have the effect of making it easier to decrypt real results, edit them, and reencrypt them. Even sending the results over an SSL connection doesn't provide additional protection against fake results, someone could create a client program that lets them submit fake results.

It would be harder to fake results, but if somebody really wanted to do it, they could anyway. Your trust of a specific person's results is still tied to your trust of the person. If somebody's results conflict strongly with the majority of the rest of the people, and you aren't quite sure if you can trust them, then it's possible they're a faker. Actually, I suppose if you trust that somebody doesn't have the technical skills to fake the results, you can trust their results. Generalizing by relations of technical skill to codec preference, that would give ogg vorbis an advantage and a WMA a disadvantage. Hey, this encryption thing sounds like a good idea after all.

Another option would be closing the sources again. Then, you can nearly make sure people aren't peeking into the code to see how encryption works. (Unless they reverse engineer the exe, but if someone goes these great lenghts to tamper my tests, I would admit defeat)

The Microsoft Crypto API would make things pretty easy. However, Windows 95, Windows NT 3.5x and Windows 4.0 would not support it out of the box.

For Windows 95, Internet Explorer (IE) 3.02 or higher installs Microsoft Crypto. For Windows NT 4.0, Service Pack 3 installs it. Windows NT 3.51 does not support Microsoft's Crypto API.

With MS Crypto installed, a default key container is created for each user. This key container takes the user's logon name as its own name, which is then used by any number of applications. It is also possible for an application to create its own key container (and key pairs), which it usually names after itself.

So maybe it would be easy to create a relatively secure system (except for the user who fires up ABC/Hr in the debugger to look at his results).

ff123

Though I am not a developer (and not knowledgable as such), I wholeheartedly agree with ff123 pursuing this idea. I have seen a debate previously on HA about the "reliability" of ABX test results, and this sort of encryption seems like it would, though not *perfectly* protect against corruption as phong and caligae point out, prevent the vast majority of people (and 100% of non-developers like me) from faking test results. It has been stated before that there should be an air of trusting members unless given a reason not to trust one of them, but a little added "insurance" could only be a good thing.


Again, I'm not a developer, but wouldn't the program generate a decryption key randomly, and though people have access to the source code used to generate that key, they still wouldn't be able to know *what* key was generated at any given time? Or are you referring more to someone's ability to access some sort of "history" of generated keys, or perhaps run a trace mode to "see" it generate a key?

I think it would be a shame to do something that would prevent the eventual creation of a Linux version of ABC/HR (either a from scratch or a port). Heck, if I ever get myself motivated, I might do that myself.

Now that I think about it (somebody please correct me if I'm wrong), almost perfect security could be achieved simply through the obfuscation of filenames.

1. Beforehand, for each test file (the original, and the compressed versions) generate two random names. Keep these secret. This could even be done for automatically for each listener on the fly.

2. The sample packs contain .flac files, one for the orginal, the others for the decoded versions of the ones where the encoder/decoder can't be included (i.e. wma, qt). These use the first of each of those pairs of filenames generated in step 1.

3. The encoding/decoding scripts would have to be a bit more sophisticated (a batch file probably won't cut it anymore.) It would hide all its activities from the user so that they can't get any hints. Via an ssl connection, it phones home and gets the pairs of filenames that correspond to each codec.

4. For each codec, in encodes to the first filename, then decodes to the second. The original flac is decoded to the second of its pair, as are the wma, qt versions, etc.

Ideally, all the decoders/encoders would be running in parallel so the user can't look at running processes and correlate them with when files appear. Or possibly, all files are decoded to memory (via the decode to standard out feature of the decoders) and dumped to disk as .wav files in random order. You could even randomize the names of the encoders/decoders. If done carefully, it might be possible to make the encoding/decoding program completely ignorant of which files are which (so even a debugger couldn't be much help to a faker.)

The same could be achieved more simply by distributing all files in .flac with random filenames, but that would make the sample packs too huge.

With this method, the tester has no way to tamper with the results, even if they're kept plain text. Comments?

In fact, I wanted to suggest encryption myself And using MS CryptoApi definately would make things easier. But I have 2 suggestions

- do not encrypt config file. since it SHOULD be decrypted on user's machine it does not really makes sence IMHO.

- do not encrypt results file, but instead and a digital signature to it. and possibly include CRC of config file and test samples.

-Eugene

I think the easiest way to go is that the test conducer encodes all files at home, decodes them, removes the offsets, flacs them and send to users using filenames that don't reflect what codec was used for each file. Only the admin knows what codec was used in each filename. Screw bandwidth consumption.

I want to see someone breaking that cryptography. :B

you can find lots of ciphers (symmetrical/antisymmetrical) implemented in a couple of libraries hosted on sf.net .
imho, it would be better to avoid os dependencies.

Re OS dependency: too late for that, the program is already very much wedded to Windows. Considerations for portability should have started from the very start if that was going to be an important aspect of this program, from the library used to play the WAV files, to the library used for the GUI. Expediency has always been more important to me than portability (call me Mr. Quick & Dirty).

BTW, if someone is going to create a portable version of this, I'd recommend what Dibrom was thinking of after the failed Java experiment: SDL for the sound library and ParaGUI for the GUI.

Re not encrypting the results file: That is the one thing that should be encrypted, so that the listener can't look at the results and make a decision based on what he sees (i.e., repeat the test, decide not to send in the results). The blatant form of cheating by hand editing the results file is not something I personally have been too worried about, but normal encryption of the results file should solve both of these problems.

The reason why a test administrator might want to obscure the config file is to keep the listener from knowing what codecs are being tested and at what settings. In this sense, it currently wouldn't matter if rjamorim's config files were encrypted or not, because his test plan is completely open.

Re Phoning home: I'd like to keep the program from doing that, if at all possible. Once I've got something which attempts to make a connection to a server, I'd have people worried about abchr being some sort of spyware.

ff123

Since we are leaving the sector of real security you could use a binary format instead of plaintext (including a checksum to see if someone tempered with a hexeditor and didn't get it right). I think writing a tool that decodes/encodes a file that is encrypted with a symmetric key would be as hard (easy) to write as a tool that decodes/encodes the binary format.

On the other hand we could also have people swearing an oath before they are allowed to submit results :-)

Sorry, how would you detect which file is which from the config file
if all had non-descriptive filenames and were in the same format?
Rjamorim is right.

Anyway, there's no unbreakable 'internal' encryption,
even SSL can be broken using a debugger.

I was thinking SDL and wxWindows, but yeah, same idea really. SDL is really simple and nice to work with (I prefer its simplicity over native APIs for most things).


Well, that would only be for the encoding/decoding script step, but it won't be necessary if we...


Right on, I'm all for that. I suppose bittorrents can help allieviate that anyway. Might exclude some modem users though. There's no way for anyone to cheat unless the test conductor is foolish enough to leak the filenames. Encryption of the results file is not necessary, since the fakers won't know which ones to tweak. It also wouldn't require any changes, or new code or anything.


Well, the test conductor would know which file is which, just not the end user.

Err, that was not exactly what I meant.

ff123: If you want, you can use my Neutrino for public-key encryption. The executable takes about 150kB, is much faster than PGP/GPG and is command-line driven.

The current version supports insane key sizes, but performs no integrity/signature verification (only encryption). I bet you don't need sig verification anyway.

Cheers

Thanks NumLOCK,

Right now it looks like I'm tending towards the MS Crypto API. Seems like this would be the easiest solution. I don't really need a speedy public key scheme, since the only thing being encrypted are the config and results files.

ff123

Look at this:
http://audio.ciara.us/stats/

The usage limit of that mirror is 5Gb. Tonight I'll pull the packages from there, and I still don't know what to do with them. >_<

Okay.

BTW, when you choose the key size, be sure to take at least RSA 1024-bit. The default, 512-bit, has already been broken by several people.

Cheers !
... crypto is fun.

PS: I personally think integration may be longer than with neutrino. Your mileage may vary though

I'll mention this thread to a friend of mine, who is an expert in security (Don Davis if you know the name). Maybe he'll volunteer, maybe not.

One way to go about securing the tool is to compile the public admin key into the binary, but not distribute it with the source. Then faking the results would require getting the key out of the binary, properly encrypting (the hardest part) and never knowing whether you got it right (you don't have the private key .

Indeed.

It's infortunate that there's no way to authenticate the results (with 100% accuracy). Even if the program were in a tamperproof box, you still could make 100's of listening sessions and submit only the best one

On public tests it's possible of course, because the listener doesn't know which sessions are the best.

That would be ok if Roberto was the only person ever to administer a test!

My current thinking is pretty much as I outlined in my first post:

1. Test admin encrypts config file with secret key, and then distributes the encrypted config file and his public key (config file cannot be secure, this is only to deter people from looking at it).

2. Listener encodes results file with the test admin public key, so that only the test admin can decrypt. This is also not secure because anybody can create a fake results file using the public key, or inspect his results before encryption using the MS debugger.

It should make cheating a bit more difficult than before, which is the goal.

ff123

Sorry, you can't encrypt using secret key. It is only for decryption.
You might want to ecrypt it with public key, then send the secret key with the program.

Oh, I was under the impression that public/secret key pairs could be used either way -- i.e., encode with the secret key, decrypt with the public, or encode with the public key, decrypt with the secret.

If it turns out that it isn't possible to encode with the secret key, then I'll probably deal with the config file some other way. But I would not distribute the secret half of the public/secret key pair.

ff123

Edit: Secret keys are typically used to encrypt symmetric keys. So is there something in the MS Crypto API which will prevent me from encrypting a message instead of a symmetric key?

you encode with the public key of the person you're writing to
it's not a problem if your public key is freely available, your secret key has to be strictly by your hands

about the wrong results you could receive, maybe you could have a look at the way the folding@home program works
if i remember well it's written somewhere on the faq that the source code isn't available because they use internal algorythm to control the integrity of the results they receive, and they want to be pretty sure that all they receive is correct

+++

This is wrong. For digital signatures you encrypt a message hash using your private key, and then everyone can verify the signature by decrypting with the public key and verifying the hash.


You were right. However, I'm not quite sure that CryptoAPI would let you do that (except when signing files/documents).

The goal of encrypting with private keys, is to certify that a document comes from YOU. So in practice, the only useful application (for private-key encryption) is that of digital signature.


No no, actually it's normal behaviour, for performance reasons: You want to encrypt a message but asymetric (ie: public/private) operations are relatively slow. So you encrypt the message with a random, good old symmetric session key, and you encrypt the key using RSA.

Then, no matter the size of the message, you only have to wait for a single asymetric operation to complete (which should take well under a second).

Numlock, you can't encrypt using secret key. Signing is not encryption.
Signature neither obscures information, nor allows one to derive it from.

I called it encryption because you need a key to interprete the result.

Ok, let's call it a private-side operation, if you want.


Well of course, but the destructive operation is when you hash the document in the first place.
The RSA operation itself (the one we were talking about) is non-destructive.



In most cases m is calculated in a destructive way (ie: one-way hash of the document), but that doesn't make the above operation destructive. If it were, then digital signatures couldn't be verified at all.

Have you considered hash collisions?
One-way hashing is destructive, for you can't get the exact message given the signature.

1. Sign the message using the hash of your secret key.
(Public key contains the hash of your secret key, which doesn't expose it)
2. Use exactly same hash function, utilizing that hash of the secret key and the message in the file.
3. Compare it with the signature included with(in) the file.

There's one more consideration I seem to have overlooked. If the test admin is the only one allowed to decrypt the results file, he will have to email back the participants with their results once the test is concluded. That may be more hassle than it's worth. I think it would be much easier to just broadcast a single password which unlocks everything after the test is complete. Similar to zip passwords (which are notoriously insecure).

Again, I'm not after the ultimate security. I just want to deter the most tempting form of listener bias (making a decision based on seeing the results file).

ff123

The test admin might as well distribute the secret key once the test is finished.

Well, the point is that I was thinking I would be able to use the default public/private key pair which belongs to the test admin, but it looks as though I'll have to generate a throwaway key pair for use just on a particular test.

ff123

Umm... that was not about hashing and collisions. It was about a one-way trapdoor function (the basis for RSA) being bijective in both ways (^e and ^d). I never claimed the hash were bijective. Obviously, hashes are designed to be as one-way as it goes.

If you want to find the message back from the hash, your problem isn't a collision probability of 2^-128. Your problem is the complexity of say, the sha-1 confusion network.


Good.


Why would you want to hash your secret key ? You're supposed to hash the message, not the key ! If you hashed the private key, how is your recipient supposed to verify the signature

No offense, but I wouldn't trust you to secure my communications B)

ff123:

If I understood you, with crypto you want to ensure that:
1. all people are testing the correct samples, and not those of another test,
2. all people can be sure that their samples really come from the test admin,
3. nobody can send faked results to you.

Points 1 and 2 can be ensured for sure.

The issue would be point 3... seems very difficult to enforce completely. For example, if everything is encrypted, then what about recording everything through "total recorder" and visually comparing the samples, during the listening session itself ? Then it becomes easier to rate the samples..

In other words, which precise (and worst) scenarios do you want to rule out/prevent/make unlikely ?

Regards

Edit: replaced "words" with "worst"

That was just 'thinking loud'. Screwed it up major. 0

/EDIT\
Scenarios to prevent:
1. Modification of results file.
2. Modifying results based on the contents of the results file.
3. Redoing a test after seeing the results.

All three are (mostly) solved using encryption.
Of course, hardcore cheater can use a debugger.
\EDIT/

Yes, this is a good list, to which I would add:

4. Easy way to allow listeners to decrypt their results files after the test is completed. This drives the need to use a throwaway public/secret key pair (the test admin cannot distribute the secret key based on his Windows userid).

Also, further down in priority is hiding the config file. But this doesn't need to really be secure.

ff123

... and a standard symmetric scheme is probably enough, I should add.


Indeed.

ff123: I think, unless one designs a clever client-server protocol to make blind testing fundamentally secure, you can just use plain AES encryption or the like. I bet you probably can't do better without running part of the application remotely.

AstralStorm: Do you see any benefit that we would lose when doing regular encryption (except for verifying the samples) ? For this purpose one can just post MD5's on the web..

There's one advantage - nobody can leak a key except the admin.
/EDIT\ (or someone having access to the secret key, of course) \EDIT/
Even a guy with the debugger.

/EDIT\ This reduces 'mass attack to force results' possibility on the test. \EDIT/

Well they can leak the public key (from inside the executable), and it's all that's needed to cheat... so where are the actual benefits over a symmetric key ?

Remember, you can't decrypt using a public key.
/EDIT\ I was talking about forging results. \EDIT/

If you have symmetric encryption, you can decrypt and reencrypt as many times as you want.

/EDIT\ Thought about it some more, and it is still brakable. You can replace the public key with your own, then just reencrypt results. \EDIT/

What you said is illogical -

Since the program itself does produce genuine results on your PC, using just the public key, then why couldn't you forge results by hand, using the very same key and a math library ?

-- E D I T --


This is a non-issue, because these re-encrypted results won't decrypt properly on the test admin's machine (ie with his private key).