unforum

[Skizz]

I should have added that a compiled version of the code is in the release folder in the ZIP. Running it creates an icon in the system tray area. Clicking on the icon brings up a dialog with some stats in it. Clicking 'Stop' terminates the application, 'Close' hides the dialog and continues processing.

Skizz

[GuyP]

I can confirm that your client reports I'm completing a work unit every 45 seconds (on a 3ghz machine) which is obviously something of an improvement. I don't know anything about coding, though, so whether it actually works isn't for me to verify.

[chimera245]

Have you run the test decrypt through your algorithm Skizz?

Basically if you apply a key:

0x0 0x0 0x0 0x0 0xde 0xad 0xbe 0xef

to the bytes:

public static byte[] TEST_DATA = { 0x97,0x13,0xc6,0x82,0xb4,0xa5,0x04,0xe5,0xb9,0x83,0x34,0x29,0x81,0x1a,0xd6,0xee,
0x7b,0xac,0x22,0xc8,0xa1,0x91,0x0b,0xcf,0xb7,0x67,0xe2,0xb2,0x8e,0xc4,0xbc,0x56,
0x92,0x5b,0x32,0xe9,0x64,0x71,0xbe,0xb2,0x3a,0x84,0xbf,0xbb,0x7c,0xee,0x06,0xb8,
0xf3,0x0d,0x0e,0xcc,0x45,0x6d,0x1a,0x74,0x98,0xee,0x66,0x9d,0x11,0x62,0x7e,0x72,
0x6e,0xf1,0x9c,0xa1,0x43,0xfb,0x51,0x0c,0xd9,0xc6,0xde,0xfd,0x19,0x2e,0x91,0x6c

You should get an ASCII answer.


Other than that - go for it. I'll keep my assault going though - just in case - but you should get through the work pretty fast if it is working correctly.

Add from further review:

I can't really comment on the Assembler yet - it has been too long since I worked in it. Can you post a result of the test above. Also I can't see where you are getting your Work Units from - even at 45 seconds per work unit it would still be a very large task for a single machine.

I have my daughter's birthday today so I'm likely to be a bit busy to do review - can others have a look at this.

[Guin]

Site and client update

[Skizz]

OK, there's something wrong with my decryption code - my implementation is OK I think (I can encrypt and then decrypt) but I may have misinterpreted something. Could someone PM me the decryption source code the client uses?
Cheers,
Skizz

[arnezami]

Just an idea.

From what I understand there is a need for keeping the source related to the server-client communication secret to prevent malicious or defective clients to ruin everything. But it may be a good idea to open up the other parts of the source: the iteration stuff, the decryption algo used, the verification process (ascii detection) etc. This way more programmers can check for (possibly disastrous) bugs or possible (speed) improvements. I mean: if there is a bug it better be detected sooner than later.

Just my 2 cents...

arnezami

PS. I've also worked on a distributed project that used checks to verify good working clients. It basicly gave a workunit to a client and (since it knew the key range) gave this client the task to find certain plaintexts and give back the keys that generated those plaintexts. The server generated about 5-10 of those plaintexts (precomputed by 5-10 random keys of which some were within the range of the work unit and some outside the range). This way only the work of clients that actually DID go through entire work units was accepted. This prevented devious clients from claiming to have done very large amounts of workunits while they in fact didn't (basicly skipping large parts of the search space) and it detected defective clients easely. The worse thing that could still happen is a client (that actually found an/the answer) not reporting this answer. But the likelyhood of that happening is relatively small if there are many participants.

[maniacfive]

Re: Site and client update

[hexDa3m0n]

OK. So i go away for a week, thinking, cool, lots of time for my PC to process and chug away....except.....two days after I go, my virus checker throws a wobbler and tries to update by dialling into work, thus hanging my internet, and causing Labour13 to crash!!!!

On a brighter note, love the improvements (to site and client), am desperatly trying to catch up on everything that has happened this week.....

[poozle]

Still waiting for proxy support cos my stupid uni connection is proxied :@

If you want me to help test the proxy section of it I would be MORE than willing.

[Skizz]

I've been looking at my code and I can't for the life of me see what's up with it. Which leads me to three possible secanrios:
1) I'm missing the bleeding obvious
2) There's a bug in the existing client code
3) The client code does something in addition to the standard RC5 algorithm.

(1) isn't a problem and can be fixed (which is why I've given away the source code).

(2) is really serious and it would be really useful to review the existing client code for bugs. If you're worried about security then either remove that portion of the code and / or send the source directly to anyone that can demonstrate programming competancy.

(3) is interesting. The card infers the RC5 algorithm from the "64/12/8", this algorithm being quite straightforward (hence, (1)). If the current client is doing extra work on top of the RC5 algorithm then the question is should it? I beleive that rccrypt program does allow for extra steps to be taken but these aren't part of the RC5 algorithm.

Skizz

[chimera245]

As I mentionned earlier I'm a little busy in RL right now to test your code - and my assemble is rusty.

The test case I gave you is not mine, but came from one of the original code zips on the old 13th Labour thread.

The way I tested the code was to compile up RCCRYPT14 in Visual Studio, Step through the code for the test combination, getting the Values for K, and the S array at each stage. I could thus follow right through to solution.

I then stepped through my code until it did exactly the same at every stage.
I then repreated this with a work unit (RCCRYPT14 and my code). Both these self tests are actually embedded in the DLL and the latter gets run every time the client starts up.

I have passed out the code for the decryption to verified users, and others have evaluated it with other means.

Once RL is a little less busy - I can have a look at the asm code - but I would suggest the stepping approach seems to be the best. BTW the above is not in any way meant as a criticism - only to try and help.

[Guin]

update

[Guin]

The new puzzle is now up on the 13th Labour Live Journal and the results of the last competitiona re available on the 13th labour site via the LJ too

This weeks prize a 13thlabour.tk tshirt for the lucky winner

[Skizz]

Hi All,

I've reworked the source to my fast client - it now correctly decodes the above test case! And, it's double the speed! (Those pesky div instructions are even slower than I thought!) I've attached the source again and the release build of the executable - no changes in it's visual appearance or use.

In the end, it was case (3) in my previous post. The rccrypt program deviates slightly from the standard RC5 algortihm as designed by Ronald Rivest. Firstly, the key scambling code in rccrypt is:

[Dranioth]

Say I have no coding experience what so ever. In comparason, how much faster is this Super Fast Client, and when would it be ready for public?