Base64

[Javiere]

Dear friends please help me find a way do base64 convertion, I know there are plugins that have this functionality but I don't need all the extra features of them. The string:

[Stuart Taylor]

the string?

[Javiere]

:o Oops sorry somehow the last parragraph didn't appear. It was just a string (all numbers) and its base64 equivalent.

[Stuart Taylor]

Have you done a search on Base64 on the forum.

A number of people (inc myself) have had a play with this.

No solutions are great in my opinion.

[Lee Smith]

check this Link

[Javiere]

Let me tell you why I need this conversion (and a couple more). It comes that beggining next month there will be a new way to control de invoices emited (In my country every invoice tax is paid by the seller) to avoid fraud, the funny thing is that of course this only applies to computer sistem generated invoices - much less than 1% actually). The new "control code" must be automatically generated by the software based on the information in the invoice. If you don't mind I'll keep contacting you for help, because there are 2 or 3 more algorithms to apply. Thank you in advance.

[Stuart Taylor]

If it's becoming law and your clients must have it... why not just make them pay for the plug-in.

[sbg2]

Perhaps something like the calc listed below? (version 7 example attached for reference)

Let ( [

// DIGIT 1

Q1 = Serial/64;

R1 = Mod(Serial;64);

F1 = Choose(R1; "0"; "1"; "2"; "3"; "4"; "5"; "6"; "7"; "8"; "9"; "a"; "b"; "c"; "d"; "e"; "f"; "g"; "h"; "i"; "j"; "k"; "l"; "m"; "n"; "o"; "p"; "q"; "r"; "s"; "t"; "u"; "v"; "w"; "x"; "y"; "z"; "A"; "B"; "C"; "D"; "E"; "F"; "G"; "H"; "I"; "J"; "K"; "L"; "M"; "N"; "O"; "P"; "Q"; "R"; "S"; "T"; "U"; "V"; "W"; "X"; "Y"; "Z"; "$"; "*");

// DIGIT 2

Q2 = Q1/64;

R2 = Mod(Q1;64);

F2 = Choose(R2; "0"; "1"; "2"; "3"; "4"; "5"; "6"; "7"; "8"; "9"; "a"; "b"; "c"; "d"; "e"; "f"; "g"; "h"; "i"; "j"; "k"; "l"; "m"; "n"; "o"; "p"; "q"; "r"; "s"; "t"; "u"; "v"; "w"; "x"; "y"; "z"; "A"; "B"; "C"; "D"; "E"; "F"; "G"; "H"; "I"; "J"; "K"; "L"; "M"; "N"; "O"; "P"; "Q"; "R"; "S"; "T"; "U"; "V"; "W"; "X"; "Y"; "Z"; "$"; "*");

// DIGIT 3

Q3 = Q2/64;

R3 = Mod(Q2;64);

F3 = Choose(R3; "0"; "1"; "2"; "3"; "4"; "5"; "6"; "7"; "8"; "9"; "a"; "b"; "c"; "d"; "e"; "f"; "g"; "h"; "i"; "j"; "k"; "l"; "m"; "n"; "o"; "p"; "q"; "r"; "s"; "t"; "u"; "v"; "w"; "x"; "y"; "z"; "A"; "B"; "C"; "D"; "E"; "F"; "G"; "H"; "I"; "J"; "K"; "L"; "M"; "N"; "O"; "P"; "Q"; "R"; "S"; "T"; "U"; "V"; "W"; "X"; "Y"; "Z"; "$"; "*");

// DIGIT 4

Q4 = Q3/64;

R4 = Mod(Q3;64);

F4 = Choose(R4; "0"; "1"; "2"; "3"; "4"; "5"; "6"; "7"; "8"; "9"; "a"; "b"; "c"; "d"; "e"; "f"; "g"; "h"; "i"; "j"; "k"; "l"; "m"; "n"; "o"; "p"; "q"; "r"; "s"; "t"; "u"; "v"; "w"; "x"; "y"; "z"; "A"; "B"; "C"; "D"; "E"; "F"; "G"; "H"; "I"; "J"; "K"; "L"; "M"; "N"; "O"; "P"; "Q"; "R"; "S"; "T"; "U"; "V"; "W"; "X"; "Y"; "Z"; "$"; "*")

]

; F4 & F3 & F2 & F1 )

Base64.zip

[Javiere]

Thanks sbg2, somehow in the "Guide" I received form the "Tax" guys 6648112111 = de3fF, using your example it's E3Ff.

I have changed the values for all the variables to be the same they use intheir dictionary to:

"0"; "1"; "2"; "3"; "4"; "5"; "6"; "7"; "8"; "9"; "A"; "B"; "C"; "D"; "E"; "F"; "G"; "H"; "I"; "J"; "K"; "L"; "M"; "N"; "O"; "P"; "Q"; "R"; "S"; "T"; "U"; "V"; "W"; "X"; "Y"; "Z"; "a"; "b"; "c"; "d"; "e"; "f"; "g"; "h"; "i"; "j"; "k"; "l"; "m"; "n"; "o"; "p"; "q"; "r"; "s"; "t"; "u"; "v"; "w"; "x"; "y"; "z"; "$"; "+"; "/".

Do you have any idea for the difference?

Edited July 5, 2007 by Guest

[Javiere]

I am using a different approach to solve this base64 convertion, but its failing, do you mind look at the attached file?

Ohh, one more thing amigos, remember I told you that all this is to implement a new policy to control the invoices in my country, well the "control code" beside using base64 they use something called "Alleged" and "Verhoeff" algorithms any clue?

Base10aBase64.fp7.zip

[comment]

Something doesn't make sense here. Using your alphabet of:

0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz+/

the result of converting decimal 6648112111 to base 64 is "6CGYFl", not "de3fF".

See the attached file.

This would be a lot easier if you had Advanced, because base conversion is recursive, and so is the Verhoeff algorithm - see:

http://www.fmforums.com/forum/showtopic.php?tid/183096/

http://www.briandunning.com/cf/616

I have no idea what "Alleged" algorithm is.

Base64.fp7.zip

[sbg2]

You added an extra digit before the 2: should be 664812111 not 664811211. Revised example attached where FullCalc produces de3fF for 664812111.

You also show 65 characters in your set. Using numbers and letters gets you to 62 characters, what are the other 2 characters?

Seeing Comments post reminds me that using the Middle function is another way to get your base 64 character. ex.

F1 = Middle ( "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz$+/" ; R1+1; 1)

Base64v2.zip

Edited July 6, 2007 by Guest

[Javiere]

Oh my! I added an extra digit! It may be because I am all confused with all this.

Friend, I have DL Verhoeff.fp7 thank you very much.

For the Alleged Alogorithm I have this information: "Alleged RC4 an algorithm based on stream cipher, very simple and capable", Please see:

http://www.4guysfromrolla.com/webtech/010100-1.shtml

And, a site in spanish with an interesting story about this algorithm:

http://www.criptored.upm.es/software/sw_m117a.htm

Saludos,

Javier

Edited July 6, 2007 by Guest

[Javiere]

IKn the instructions received to produce the "control code" I was told to use this set:

"0"; "1"; "2"; "3"; "4"; "5"; "6"; "7"; "8"; "9"; "a"; "b"; "c"; "d"; "e"; "f"; "g"; "h"; "i"; "j"; "k"; "l"; "m"; "n"; "o"; "p"; "q"; "r"; "s"; "t"; "u"; "v"; "w"; "x"; "y"; "z"; "A"; "B"; "C"; "D"; "E"; "F"; "G"; "H"; "I"; "J"; "K"; "L"; "M"; "N"; "O"; "P"; "Q"; "R"; "S"; "T"; "U"; "V"; "W"; "X"; "Y"; "Z"; "+"; "/"

Note the difference in the last 2 chars.

Using the example Base64V2, produces different results compared with the suplied examples please see the attachment

tests.png.zip

[sbg2]

Any chance you can post the "instructions" here? That way we won't have to keep guessing.

[comment]

So change the variable $alpha defined in my script to:

"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ+/"

Everything else is the same.

I too think you should post the entire instructions, from A to Z. It's no use doing it piece by piece.

[Javiere]

Dear sbg2 and the rest of amigos, I did not want to bother you with all the instructions but, you are right is better if I tell you all the story. Before I forget, finally I found a solution for the base64 conversion, I will attach it in another post , I tested it and works fine, but as you will see it's not all, the problem is not resolved yet...

As I told ypu before all this comes due to a new control of our government to attack tax frauds in the emission of invoices. They have instructed all the enteprises to comply with a new policy according to the rules described in the attachment Invoice_Instructions.pdf.zip can yuo please take a look at it? As I see the procedure is very complicated and cumbersome. I am afraid it will do litle to prevent fraud since it is mandatory only (of course) for electronically emitted invoices, but you can still produce invoices manually. In the other hand, it's becoming law an laws are there to be abeyed.

Thank you for your patience and ineterres in this case.

Invoice_Instructions.pdf.zip

Tetrap_NSF3.pdf.zip

Edited July 6, 2007 by Guest

[Javiere]

:o Yes, Carpal Tunnel I didnt do so because I don't want to "abuse" of your kindness. Please see my previos post, there you will find all the information. I'am attaching here a solution that works fine to convert base10 to base64. Tested

Base10aBase64v2.fp7.zip

[Javiere]

Just to have you updated, I have already solved the base64 conversion and Verhoeff (see http://www.briandunning.com/cf/616), I am now trying to figure out the "Alleged RC4" algorithm.

Saludos,

Javier

[comment]

I have looked at your instructions. Everything there is easy - until you get to the last stage, the RC4 encryption. I don't see a good description of the algorithm anywhere. By "good description" I mean one that would allow you to do this using paper and pencil only. Everyone is assuming you are doing this in a programming language, but Filemaker is not a programming language - it does not let you operate directly at the bit level. I suppose it's possible to figure it out eventually, but it would take a LOT of work.

I'd suggest you look at some alternatives, e.g. use AppleScript to send this to the Terminal (I think you can do RC4 through a command line), or look for a plugin.

[Javiere]

Uhmm Carpal, I have found this implementation of RC4 I beleive it's in C or C++ (both Chinese for me). Does it needs capacities not covered by FM?

This is an implementation of the RC4 (or "ARCFOUR" for copyright purposes) stream cipher.

There are two steps to the cipher. First, the KSA uses a supplied key to initialize the "state" matrix. Then, the PRGA uses the state to generate pseudo-random output of any desired length. called the keystream. For encryption purposes, this keystream is XOR'd by the plaintext to yield ciphertext. For decryption, the keystream is XOR'd by the ciphertext to yield plaintext.

Code Usage: 
Encrypting and decrypting text is performed the same way. A key is used to initialize an array, which is permutated and generates byte values which are then XOR'd by the text to encrypt/decrypt.

void ksa(unsigned char state[], unsigned char key[], int len) -- The KSA function must be called first. Using the provided key, it scrambles the state array. After this function, the key is not needed.
unsigned char state[] -- This is the state that will be initialized by the key. It must be 256 bytes in size.
unsigned char key[] -- This is the key to use for encryption/decryption.
int len -- The length of the key, in bytes.

void prga(unsigned char state[], unsigned char out[], int len) -- The PRGA function generates the keystream. The state is permutated to generate each byte of the keystream, and its original values are not saved. So generating 8 bytes of output in one function call followed by 8 more bytes of output in seperate function call will yeild the same keystream as generating all 16 bytes of output in one function call. unsigned char state[] -- The state array initialized by ksa(). unsigned char out[] -- The array to store the output in. This is XOR'd by the plaintext/ciphertext. It must be the length of the "len" (below) value. int len -- This is the number of bytes to generate.

// Key Scheduling Algorithm

// Input: state - the state used to generate the keystream

// key - Key to use to initialize the state

// len - length of key in bytes

void ksa(unsigned char state[], unsigned char key[], int len)

{

int i,j=0,t;

for (i=0; i < 256; ++i)

state = i;

for (i=0; i < 256; ++i) {

j = (j + state + key[i % len]) % 256;

t = state;

state = state[j];

state[j] = t;

}

}

// Pseudo-Random Generator Algorithm

// Input: state - the state used to generate the keystream

// out - Must be of at least "len" length

// len - number of bytes to generate

void prga(unsigned char state[], unsigned char out[], int len)

{

int i=0,j=0,x,t;

unsigned char key;

for (x=0; x < len; ++x) {

i = (i + 1) % 256;

j = (j + state) % 256;

t = state;

state = state[j];

state[j] = t;

out[x] = state[(state + state[j]) % 256];

}

}int main()

{

unsigned char state[256],key[]={"Key"},stream[1024];

int len=9,idx;

ksa(state,key,3);

prga(state,stream,len);

for (idx=0; idx < len; idx++)

printf("%02X ",stream[idx]);

return 0;

}

[comment]

Does it needs capacities not covered by FM?

I don't know. I have already seen that, and much of it is Chinese to me too. One thing is clear: it operates on a bit stream. All the input is binary. You cannot do this in FM, at least not directly. You have to translate all these operations, and you have to translate them correctly.

For example, I found a Javascript implementation, which makes a little more sense to me. But the output is different than expected. That doesn't mean it's incorrect - it just uses another form of encoding. If you use the same algorithm for both encrypting and decrypting, it doesn't matter. But you need a prescribed output to match what your tax authorities specified.

[Javiere]

That's correct, I'll try to find a better descrption of the algorithm, if I find it I'll post it here OK?. Thank you friend

[Javiere]

Dear Carpal and friends, I have found this pdf containing the pseudocode for the RC4 Algorithm, implementing it in Fm implies access to byte level manipulation? If not can you please help

me with it? I'm stuck with this

Gracias,

Javier

EspAllegedRC4.pdf

[comment]

I believe this can be done, but it would take a lot of work - at least a day to get something that works, more to optimize it for Filemaker.

[Javiere]

Yes indeed, it implies converstion to binary, apply XOR and then do another base conversion, I'll try to see what I can do. Thank you amigo.