New SimpleCrypt page
-
So I've played a bit around I've come to the conclusion that I'm using QDataStream incorrectly.
My Test Code: main.cpp
@
#include <QString>
#include <QDebug>
#include <QBuffer>
#include <QDataStream>
int main(){
QString txStr = "Hello world!";
QString rxStr;QBuffer txB;
txB.open(QIODevice::ReadWrite);
QDataStream s(&txB);
qDebug() << txB.size();
s << txStr;
qDebug() << txB.size();
s >> rxStr;
qDebug() << rxStr;
return 0;
}
@My Output:
0
28
""So the buffer is being filled but not correctly being read out.. why not?
-
That's an easy question. Your problem is the stream position:
you write to the stream, then start reading after the written bytes :-)
try out the following:
@
#include <QString>
#include <QDebug>
#include <QBuffer>
#include <QDataStream>
int main()
{
QString txStr = "Hello world!";
QString rxStr;QBuffer txB; txB.open(QIODevice::WriteOnly); QDataStream s(&txB); qDebug() << txB.size(); s << txStr; qDebug() << txB.size(); txB.close(); // sets stream position to 0 !!! txB.open(QIODevice::ReadOnly); QDataStream s2(&txB); s2 >> rxStr; qDebug() << rxStr; return 0;}
@or use a seek in between
@
#include <QString>
#include <QDebug>
#include <QBuffer>
#include <QDataStream>
int main()
{
QString txStr = "Hello world!";
QString rxStr;QBuffer txB; txB.open(QIODevice::WriteOnly); QDataStream s(&txB); qDebug() << txB.size(); s << txStr; qDebug() << txB.size(); txB.seek(0); // sets stream position to 0 !!! s >> rxStr; qDebug() << rxStr; return 0;}
@I did not compile the code, so it might contain typos
-
Aha, got it all sorted out, thanks
I had my suspicions on that, but thought that the "<<" and ">>" operators may use seperate index variables.
Andre: it would be great if you could incorporate in the Example usage code the following so it works out of the box.
@
buffer.open(QIODevice::WriteOnly);
buffer.close();
buffer.open(QIODevice::ReadOnly);
@Because newbies like myself:
- copy + paste + compile
** if it works -> adapt to needs
** if it doesn't -> get lost in the simplest things
Although I must admit that I am learning loads of things through all these problems I get myself into.
Gerolf: Once again thanks for your quick and effective response.
- copy + paste + compile
-
paucoma, thank you for your comments and suggestions. I have changed the wiki page accordingly. I am glad you solved the problem, and that it turned out the class itself was not at fault ;-)
I must admit that I wrote the examples directly in the wiki page, and thats when errors like these happen. Sorry about that! I hope the current version is more managable? Note that I was talking about "at the other end", implying that the decryption code was not meant to be used in the same function (and thus, implicitly, with the same buffer).
-
Hi Andre,
one suggestion to the wiki page:
In the section SimpleCrypt in use it would be nice to have a list of the encryp/decrypt functions. You state thete are two times 4, but not the names :-)
this means searching inside the code :-)The rest sound really god. Thanks for the article.
-
[quote author="Gerolf" date="1300958192"]Hi Andre,
one suggestion to the wiki page:
In the section SimpleCrypt in use it would be nice to have a list of the encryp/decrypt functions. You state thete are two times 4, but not the names :-)
this means searching inside the code :-)The rest sound really god. Thanks for the article.[/quote]
Fair enough, done. :-)
Thanks for the praise.
-
Hi Andre,
I'm currently reading your second article, and found the following "here":http://developer.qt.nokia.com/wiki/SimpleCrypt_algorithm_details#00f4e5788aab6d3546bb433842dbbefc :
bq. The payload data block’s contents are encrypted with a four byte (quint64) key.
quint64 is a 64 bit integer, which means 8 byte.
so also in the snipet page, you say:
@
SimpleCrypt crypto(Q_UINT64_C(0x7F29B208)); //some random number
@this is just a 32 bit number, not 64 bit.
@
void SimpleCrypt::splitKey()
{
m_keyParts.clear();
m_keyParts.resize(4);
for (int i=0;i<4;i++) {
quint64 part = m_key;
for (int j=i; j>0; j--)
part = part >> 8;
part = part & 0xff;
m_keyParts[i] = static_cast<char>(part);
}
}
@this also only uses 4 bytes, not 8.
-
some additional topics:
in "Decrypted payload":http://developer.qt.nokia.com/wiki/SimpleCrypt_algorithm_details#2d478ba9ee3cf03e338b506b1a0292dc
SH1 and CRC have the same description:
bq. In case the Protection Checksum flag has been set, the layout of the decrypted payload looks like this:
I think this is just a copy paste error.
As I'm through now, no more things :-)
Very good article, interesting to read. Thanks. -
Hi Andre.
First of all, thanks for sharing your code. :-)I was playing with this algorithm, but I noticed a strange situation: sometimes these work well, sometimes not.
This is the string which I have tested :
10197016915918185882701231384169178913312058269-10750535699546572956586080750006397
The key is: 13775729I tested both with string and binary data (there are several integer values).
So if I encrypt this string, and then decrypt it, sometimes original string is equal with decrypted string, sometimes differ.
-
A small test is something like :
@
QString cryptSerialNumber;void testCrypt()
{
SimpleCrypt processSimpleCrypt(13775729);
QString uniqueString("10197016915918185882701231384169178913312058269-10750535699546572956586080750006397");
cryptSerialNumber = processSimpleCrypt.encryptToString(uniqueString);
}void testDecrypt()
{
SimpleCrypt processSimpleCrypt(13775729);
QString uniqueString = processSimpleCrypt.decryptToString(cryptSerialNumber);
}
@Sometimes decrypted "uniqueString" is the same as the original, but sometimes is :
1019701691591818588270123138416917891691033658269-10750535699546572956586080750006397, almost the same with original, but not the same :-)