Encrypting and knowing if it's encrypted

Well, off course a better system is possible, but I think it's robust enough: the possibility of someone writing a phrase that starts with the magic key exists, but it is very low, even more if you think that this is a file format (the next line needn't be user input, in fact in my case it is numerical data), also the magic key is added just after the encryption is done... so I'm pretty sure that the possibility of the magic key being the same as the first encrypted blob is very very low. And much lower if you use a long magic key. So in my case, kryptkat, the possibility of that happening equals 0 because I choose the magic key and obviously if the next line is numerical data I wouldn't use much numbers in it. Also this possibility that you mention is what I wanted to solve adding the newline after the magickey but it can be accomplished just as it's been said checking for the length not the \n.

Originally Posted by beta3designs

Well, off course a better system is possible, but I think it's robust enough: the possibility of someone writing a phrase that starts with the magic key exists, but it is very low, even more if you think that this is a file format (the next line needn't be user input, in fact in my case it is numerical data), also the magic key is added just after the encryption is done... so I'm pretty sure that the possibility of the magic key being the same as the first encrypted blob is very very low. And much lower if you use a long magic key. So in my case, kryptkat, the possibility of that happening equals 0 because I choose the magic key and obviously if the next line is numerical data I wouldn't use much numbers in it. Also this possibility that you mention is what I wanted to solve adding the newline after the magickey but it can be accomplished just as it's been said checking for the length not the \n.

You can reduce that even further by deliberately breaking the rules of grammar and using statistically infrequent characters... Q} would be one example... In proper english spelling Q is always followed by a U... Most people don't use curly braces in normal text.

Off course, you are right
But what I wanted to emphasize is that it is a file and it is used for a program it is not plain text so the next line or word right after the magic key is not necessarily user input and, in my case, it is in fact program data so it is impossible that it happens to be the same as the magic key so as to say that I don't think that a better system is needed, the system seems to me robust. And as far as I'm concerned and as you have confirmed I'm not the first to use it and many image formats use it.

Originally Posted by beta3designs

Off course, you are right
But what I wanted to emphasize is that it is a file and it is used for a program it is not plain text so the next line or word right after the magic key is not necessarily user input and, in my case, it is in fact program data so it is impossible that it happens to be the same as the magic key so as to say that I don't think that a better system is needed, the system seems to me robust. And as far as I'm concerned and as you have confirmed I'm not the first to use it and many image formats use it.

Never say "impossible"... as unlikely as it is, my example corresponds to an unsigned short int with a value of 0x7D51 or 32,081 on a little endian system.

Just to give you some idea how screwy this can get... Here's what it takes to sort out what kind of file you are opening in the wonderful world of Unicode...

Code:

// open and translate file
BOOL M3ULaunch(PWCHAR FileName)
  { PBYTE  rf;      // raw file data
    DWORD  br;      // bytes read
    // load the raw file
    { HANDLE pl;    // playlist file handle 
      DWORD  fs;    // file size
      // get path to file
      wcsncpy(FilePath,FileName,MAX_PATH);
      PathRemoveFileSpec(FilePath);
      wcscat(FilePath,L"\\");
      // open the file
      pl = CreateFile(FileName,GENERIC_READ,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
      if (pl == INVALID_HANDLE_VALUE)
        Exception(GetLastError());
      fs = GetFileSize(pl,NULL);        
      rf = calloc(fs + 2, sizeof(BYTE));
      if (! ReadFile(pl, rf, fs, &br, NULL))
        Exception(GetLastError());
      CloseHandle(pl);  
      if (br != fs)
        Exception(0xE00640007); } 
    try                                   
     { DWORD bom = *(DWORD*)rf;
       if ((bom == 0x0000FEFF) || (bom == 0xFFFE0000))  // utf32le bom  
         Exception(0xE0640002);                         // utf32be bom  
       else if ((bom & 0xFFFF) == 0xFFFE)               // utf16be bom
         { FlipEndian(rf,br);
           CopyWChar((PWCHAR) rf + 1); }
       else if ((bom & 0xFFFF) == 0xFEFF)               // utf16le bom
         CopyWChar((PWCHAR) rf + 1);  
       else if ((bom & 0xFFFFFF) == 0xBFBBEF)           // utf8 bom
         CopyMByte(rf + 3, br - 3);
       else                                             // no known bom, probe the file
         { if (! memchr(rf, 0x00, br))                  // 8 bit text has no nulls
             CopyMByte(rf,br);                          // ansi / utf8 no bom
           else 
            { PBYTE lf = memchr(rf,0x0A,br);            // lf is always present as 1 byte.
              if (!lf) 
                Exception(0xE0640003);
              if ((!(*(DWORD*)(lf - 3) & 0x00FFFFFF)) ||    //utf32be no bom
                   (!(*(DWORD*)lf & 0xFFFFFF00)))           //utf32le no bom
                 Exception(0xE0640002);    
              if ((lf - rf) & 1)                        // big endian? (lf at odd offset)
                FlipEndian(rf,br);                      // utf16be no bom  
              CopyWChar((PWCHAR) rf);  } } }            // utf16le no bom
     finally  
      { free(rf); }
    return 1; }

Yeah shouldn't say impossible for sure, but I was just referring to my particular case where I think probabilities of this are veeery low, anyways nice to see some more complicated example code like this

@CommonTater
[rant]
Your indentation and brace placement practices drive me up the wall, man! >_<
[/rant]

Originally Posted by msh

@CommonTater
[rant]
Your indentation and brace placement practices drive me up the wall, man! >_<
[/rant]

Yes, and?

FWIW... the common standards for indentation etc. drive me right up the wall, but you don't hear me crying about it.

Originally Posted by msh

@CommonTater
[rant]
Your indentation and brace placement practices drive me up the wall, man! >_<
[/rant]

I wouldn't worry about it too much; he is Canadian after all.......

Originally Posted by CommonTater

Yes, and?

FWIW... the common standards for indentation etc. drive me right up the wall, but you don't hear me crying about it.

Oh, I'm just ranting! Hence the tags. I'm well aware of your opinions on indentation standards. ::beer::

Originally Posted by AndrewHunter

I wouldn't worry about it too much; he is Canadian after all.......

HEY! I resemble that remark!

point was you always have to leave a certain number of bits for the variable if it is encrypted or not. the code does not do that. if you are going to have a spot for a status tag it always has to be there. with the same number of bits. it is the format that tells where the "blob" data starts. then if it is the same as the "blob" it does not matter because you now are looking in two different areas.

bbbbbbb[tag][blob]etc.

Originally Posted by kryptkat

point was you always have to leave a certain number of bits for the variable if it is encrypted or not. the code does not do that. if you are going to have a spot for a status tag it always has to be there. with the same number of bits. it is the format that tells where the "blob" data starts. then if it is the same as the "blob" it does not matter because you now are looking in two different areas.

bbbbbbb[tag][blob]etc.

Take a look at the unicode sample I posted... No the tag does not always have to be there. Good software will know what to do if it isn't.