http://www.crypt.co.za Welcome to The Twylite Zone. Fri, 12 Feb 2010 01:18:44 +0000 hourly 1 http://wordpress.org/?v=3.2.1 http://www.crypt.co.za/post/62#comment-37 AJK Fri, 12 Feb 2010 01:18:44 +0000 http://www.crypt.co.za/post/62#comment-37 I started reading the OpenID docs about an hour ago and came up with this attack and promptly found your page describing it. It's scary how easy it was to figure out that OpenID isn't very good at authentication. I'm having a little trouble seeing how, if all URLs are https, you're not okay. Of course, this means I bought a SSL server certificate for my OpenID URL, so why not just buy a SSL client certificate instead? I started reading the OpenID docs about an hour ago and came up with this attack and promptly found your page describing it. It’s scary how easy it was to figure out that OpenID isn’t very good at authentication. I’m having a little trouble seeing how, if all URLs are https, you’re not okay. Of course, this means I bought a SSL server certificate for my OpenID URL, so why not just buy a SSL client certificate instead?

]]> http://www.crypt.co.za/post/57#comment-35 anderson Fri, 15 May 2009 04:29:47 +0000 http://www.crypt.co.za/post/57#comment-35 Bad research...rnI need to find an article.. any news site.. published in the last 7 days and then say in a paragraph or 2 why it is bad research. And.. i cant find any.rnhelp? haha Bad research…rnI need to find an article.. any news site.. published in the last 7 days and then say in a paragraph or 2 why it is bad research. And.. i cant find any.rnhelp? haha

]]> http://www.crypt.co.za/post/44#comment-33 Mark Tue, 20 Jan 2009 12:34:01 +0000 http://www.crypt.co.za/post/44#comment-33 Hi, I was looking round to see how the CSV format is described and came across your post. I'm trying to parse a CSV file and I'm comparing my result to that of Excel. rnrnI agree with your EBNF description except that I noticed that Excel does produce """hello" in a CSV file if you type ["hello] (without the square brackets) in a cell. Therefore, I would change your description of atom to allow "" as the first two characters rather than forcing them to be preceded by [qchar]:rnrn atom ::= [char]* | "[qchar]*[""[qchar]*]*"rnrnI am assuming that in your definition [qchar] means any 1 character except " while [qchar]* means any character except " repeated 0 or more times.rnrnCheersrnrnMark Hi, I was looking round to see how the CSV format is described and came across your post. I’m trying to parse a CSV file and I’m comparing my result to that of Excel. rnrnI agree with your EBNF description except that I noticed that Excel does produce “”"hello” in a CSV file if you type ["hello] (without the square brackets) in a cell. Therefore, I would change your description of atom to allow “” as the first two characters rather than forcing them to be preceded by [qchar]:rnrn atom ::= [char]* | “[qchar]*[""[qchar]*]*”rnrnI am assuming that in your definition [qchar] means any 1 character except ” while [qchar]* means any character except ” repeated 0 or more times.rnrnCheersrnrnMark

]]> http://www.crypt.co.za/post/27#comment-28 Twylite Mon, 19 Jan 2009 07:16:21 +0000 http://www.crypt.co.za/post/27#comment-28 Hi meme,rnrnI used the reference implementation from Wheeler & Needham's paper. So long as you are running on a little-endian machine (e.g. x86) it should work.rnIf you are on a big-endian machine (e.g. Sun Sparc) you can convert the key and block to the appropriate representation using a function like this:rnrnunsigned long param_readU32L(unsigned char* buffer, unsigned long bufLen, unsigned long offset, unsigned long *result)rn{rn unsigned char* p = 0;rn // First check that the buffer + offset + 32 bits is valid.rn if (bufLen<offset +4) {rn return 1;rn }rnrn // acquire unsigned char* p = buffer + offsetrn p = buffer + offset;rn *result = (*p) + (*(p+1) << 8) + (*(p+2) << 16) + (*(p+3) << 24);rnrn return 0;rn}rnrnUse that on each 4-byte segment of the input key & block, and the following function on each 4-byte segment of the output block:rnrnunsigned long param_writeU32L(unsigned char* buffer, unsigned long bufLen, unsigned long offset, unsigned long value)rn{rn unsigned char* p = 0;rn // First check that the buffer + offset + 16 bits is valid.rn if (bufLen<offset+4) {rn return 1;rn }rnrn // acquire unsigned char* p = buffer + offsetrn p = buffer + offset;rn *p = (unsigned char)(value&0x000000FF);rn ++p;rn *p = (unsigned char)((value>>8)&0x000000FF);rn ++p;rn *p = (unsigned char)((value>>16)&0x000000FF);rn ++p;rn *p = (unsigned char)((value>>24)&0x000000FF);rnrn return 0;rn}rnrnI've never tested on a big-endian platform though, so YMMV.rnrnCheers</offset> Hi meme,rnrnI used the reference implementation from Wheeler & Needham’s paper. So long as you are running on a little-endian machine (e.g. x86) it should work.rnIf you are on a big-endian machine (e.g. Sun Sparc) you can convert the key and block to the appropriate representation using a function like this:rnrnunsigned long param_readU32L(unsigned char* buffer, unsigned long bufLen, unsigned long offset, unsigned long *result)rn{rn unsigned char* p = 0;rn // First check that the buffer + offset + 32 bits is valid.rn if (bufLen>8)&0x000000FF);rn ++p;rn *p = (unsigned char)((value>>16)&0x000000FF);rn ++p;rn *p = (unsigned char)((value>>24)&0x000000FF);rnrn return 0;rn}rnrnI’ve never tested on a big-endian platform though, so YMMV.rnrnCheers

]]> http://www.crypt.co.za/post/27#comment-27 meme Sun, 18 Jan 2009 09:15:47 +0000 http://www.crypt.co.za/post/27#comment-27 can you send me the c code that works with little endian caus i can't work the c code from wikipedia with little endian. can you send me the c code that works with little endian caus i can’t work the c code from wikipedia with little endian.

]]> http://www.crypt.co.za/post/27#comment-26 Twylite Tue, 28 Oct 2008 15:04:35 +0000 http://www.crypt.co.za/post/27#comment-26 My bad, q = 6+52/n -- I should have said "q uses" instead of "q =" My bad, q = 6+52/n — I should have said “q uses” instead of “q =”

]]> http://www.crypt.co.za/post/27#comment-25 Steve Davis Tue, 28 Oct 2008 14:59:16 +0000 http://www.crypt.co.za/post/27#comment-25 Thanks for that extra info :) --yes, I am receiving strings in NBO but I just checked an x86 architecture and indeed the results are little-endian on that. One question - isn't (according to the reference implementation) the number of rounds q = 6+52/n rather than either 52/n or 52/(n+1)? Is that a typo on your part or have I got another issue here! Thanks for that extra info :) –yes, I am receiving strings in NBO but I just checked an x86 architecture and indeed the results are little-endian on that. One question – isn’t (according to the reference implementation) the number of rounds q = 6+52/n rather than either 52/n or 52/(n+1)? Is that a typo on your part or have I got another issue here!

]]> http://www.crypt.co.za/post/27#comment-24 Twylite Tue, 28 Oct 2008 07:48:57 +0000 http://www.crypt.co.za/post/27#comment-24 Thanks for the comment. These are the notes from my code on the potential incompatibilities between XXTEA implementations:rnrn--rnWarning #1: Incompatible implementations existrnThere are several implementations of XXTEA in circulation that do not agree with the reference version. The calculation of q (number of rounds) uses 52/(n+1) instead of 52/n, and the upper limit of the "for p" loop is n rather than n-1. One Java implementation even appends the block length to the block before encryption, resulting in a ciphertext longer than the plaintext. Such implementations are not compatible with the reference implementation, nor with this implementation.rnrnWarning #2: Platform incompatibilitiesrnThe reference implementation is given in C and uses signed long arrays (long*) for the key and data. If care is not taken in the conversion of keys and data from binary (unsigned char*) to long* -- for example by just using a type cast -- then keys, plaintext and ciphertext on a little endian platform (e.g. x86) will not be compatible with the same binary values used on a big endian platform (e.g. sparc). This implementation assumes that binary keys and data should be interpreted as 32-bit little endian values, and will do that consistently on all platforms.rn--rnrnIt is not clear what endianness the original authors assumed, but there are hints that their code was intended to run on Linux/x86 (little endian). In addition most of the implementations I have encountered assume little endian.rnrnI have calculated some common "wrong answers" (according to the reference implementation) for key=0 plaintext=0:rnrnReference implementation (q=52/n ; little endian): ab043705 808c5d57rnq = 52/(n+1): 4de1bc5b 62352db0rnbig endian: 053704ab 575d8c80rnbig endian ; q = 52/(n+1): 5bbce14d b02d3562 Thanks for the comment. These are the notes from my code on the potential incompatibilities between XXTEA implementations:rnrn–rnWarning #1: Incompatible implementations existrnThere are several implementations of XXTEA in circulation that do not agree with the reference version. The calculation of q (number of rounds) uses 52/(n+1) instead of 52/n, and the upper limit of the “for p” loop is n rather than n-1. One Java implementation even appends the block length to the block before encryption, resulting in a ciphertext longer than the plaintext. Such implementations are not compatible with the reference implementation, nor with this implementation.rnrnWarning #2: Platform incompatibilitiesrnThe reference implementation is given in C and uses signed long arrays (long*) for the key and data. If care is not taken in the conversion of keys and data from binary (unsigned char*) to long* — for example by just using a type cast — then keys, plaintext and ciphertext on a little endian platform (e.g. x86) will not be compatible with the same binary values used on a big endian platform (e.g. sparc). This implementation assumes that binary keys and data should be interpreted as 32-bit little endian values, and will do that consistently on all platforms.rn–rnrnIt is not clear what endianness the original authors assumed, but there are hints that their code was intended to run on Linux/x86 (little endian). In addition most of the implementations I have encountered assume little endian.rnrnI have calculated some common “wrong answers” (according to the reference implementation) for key=0 plaintext=0:rnrnReference implementation (q=52/n ; little endian): ab043705 808c5d57rnq = 52/(n+1): 4de1bc5b 62352db0rnbig endian: 053704ab 575d8c80rnbig endian ; q = 52/(n+1): 5bbce14d b02d3562

]]> http://www.crypt.co.za/post/27#comment-23 Steve Davis Mon, 27 Oct 2008 22:23:40 +0000 http://www.crypt.co.za/post/27#comment-23 If instead of ...rnab043705 808c5d57rn... i get ...rn053704ab 575d8c80rn...what does this say about endian-ness? Which is actually more correct? If instead of …rnab043705 808c5d57rn… i get …rn053704ab 575d8c80rn…what does this say about endian-ness? Which is actually more correct?

]]> http://www.crypt.co.za/post/59#comment-36 Reg Thu, 28 Aug 2008 16:30:03 +0000 http://www.crypt.co.za/post/59#comment-36 Interesting.rnrnAren't you glad you studied psychology?rnrnPeople need fads. Fads make the innovators feel important, imitators knowledgeable and the critics wise. Whether or not they work is immaterial.rnrnAs for technologies and methodologies: the less knowledge resources they require to work the more likely they are to work once the fad is past.rnrnTrue Solution Value = (1/Real Knowledge Required * Fad Ubiquity/Years in service) * Actual Business Benefit Interesting.rnrnAren’t you glad you studied psychology?rnrnPeople need fads. Fads make the innovators feel important, imitators knowledgeable and the critics wise. Whether or not they work is immaterial.rnrnAs for technologies and methodologies: the less knowledge resources they require to work the more likely they are to work once the fad is past.rnrnTrue Solution Value = (1/Real Knowledge Required * Fad Ubiquity/Years in service) * Actual Business Benefit

]]>