I can't find any help to implement PROV_RSA_AES CSP in c++. is there any article or book to help me out with it?
Here is an article about it.
Here is another one.
i just want to use one, i figured
how to get context but i'm still
thinking about the size of buffer i
need to use for CryptEncrypt() to get
it working with aes256 ? i also want
to use random salt.
AES256 in CBC-mode with PKCS#7-padding (which is the default) will need a buffersize that is the input-data rounded up to the next multiple of 16 (but always at least one byte more). Ie. 35 -> 48, 52 -> 64, 80 -> 96.
There is no salt involved in AES256. Are you talking about key-derivation? Or do you mean the IV?
Related
I don't make sure, but I think the ScadaLTS no have the modbus 16 function. I need write in 9 registers simultaneously, but the data type that ScadaLTS give does not satisfy my need. I did try to use the type data "fixed length string" but I can't represent the code 0 in ASCII, if I could, it would work.
Finally, I hope to find help and thank you very much in advance.
Modbus function 16 is writing multiple holding register address at once, we cannot write it one by one, and must use fc 16 code. But there is no option to write to multiple address at modbus datapoint. I need this feature also,
Which is the standard size of the MAC generated with SHA-2?
it is safe if I trunk the message and then send it to destination ?
Thank you in advance for your consideration
First of all, do not use only the SHA2 hash funcion, but use HMAC (with SHA2).
Now for answering your question: In theory, you can use any size for your MAC, depending on your security requirements. However, the most recommended standard tag size is 128 bits (16 bytes).
I wonder how mobile phone companies generate both PIN and PUK for their SIM cards?
I have a large database of already generated codes, this database contains 3 columns:
* MSIN : Mobile Subscriber Identification Number (10 digits)
* PIN : Personal Identification Number (4 digits)
* PUK : Personal Unblocking Code (8 digits)
So far, maybe both PIN and PUK are generated from MSIN because the MSIN column is incrementing, while others, are generated with a logic, something like;
MSIN PIN PUK
1000000000 3234 20005627
1000000001 5993 92870018
1000000002 3465 30327846
...
is it possible to know how this serials are generated? Using the existing database is it possible to guess the algo used?
I'm asking this for the sake of knowledge only not to use the provided information in any illegal activity ;)
thanx.
UPDATE
I searched for how many times some pin codes are repeated and found this
0000 –> 261 times
1111 –> 429982 times
2222 –> 275
3333 –> 233
4444 –> 279
5555 –> 277
6666 –> 242
7777 –> 263
8888 –> 249
9999 –> 242
the pin 1111 is used more than others! so maybe the algo is changed from time to time.. or ther's no logic at all inside :(
UPDATE 2
I checked the MSIN and found that they make jumps in the incrementing system, so for example;
1011000000
1011000001
… here they followed incrementing until 1011499999
1011499999 and they jumped to 1031000000
1031000000
… the same thing here
1031299999
1131000000
…
this leads to an idea that whenever they want to issue new cards, lets say 500 000 cards, they start with a new MSIN that doesn't follow the incrementing rule in the database and the may change the algo behind the code generation (that's why we find in some cases they issued all the next cards with pin 1111)
The answer can go from really easy to pretty complex.
If I had to design the system, the f function (Pin,Puk) = f(MSIN) wouldn't be easy to guess, and, moreover, not reversible (meaning if you know (pin,puk) you cannot guess MSIN).
Because the subject is around security and payment, you can probably expect a complex function.
Unless it is documented somewhere on the net (which I doubt) it is very unlikely you will find the function f.
If we make the assumption that PUK/PIN are generated from the MSIN, there's a virtually infinite number of ways they could be doing this. To take one (reasonable) example, they could be using an HMAC. Even assuming you knew what hash algorithm they're using, you'd still have to determine the secret key, and the search space for that is on the order of 2^160 (for HMAC-SHA1) - totally impractical to search exhaustively.
The only chance you have is if they're doing something stupid, like using an easily guessed or determined algorithm to generate the PIN/PUK - and there's no practical mechanical procedure to work that out, just trial, error, and intuition.
Usually its not the mobile network operator who generates the PIN and PUK. The SIM card manufacturer does this unless ordered otherwise by the operator.
What makes you believing that one can calculate SIM and/or PUK from the MSIN? Neither the network operator nor the SIM manufacturer would have any advantage from this. I would assume that PIN and PUK are as random as economically feasible in order to implement the intended security.
However, I find the 1111 anomaly interesting. Is your sample right from manufacturing? Or did you get an HLR dump? The latter one might provide an explanation for the 1111 cumulation: People change their PIN to something easy to remember and to type, 1111 would be the most common candidate for this.
Where can I get the structure for an HID device?
For example:
raw data from a device, using GetRawInputData:
( 0 137 117 0 146 130 24 128 0 )
( 0 137 117 0 146 130 8 128 0 )
/\
at this I can see that || there is being a button released
that means, at the 6-th char at 4-th bit
By analyzing the raw stream I can figure out where are the buttons, switches and analog data. Is there a way to ask this information from Windows.
My main goal is to basically get structure:
Button - 6th char, 4th bit.
Analog - 2nd char
Switch - 6th char, 0-3th bit.
The only solution I found was HID Descriptors. But I'm not sure how to use them.
After reading documentation I felt like running into a brick wall. Is there
maybe a good example how to use them or a book that describes them better. (Or a easier way
doing it without descriptors)
I found HidP_GetButtons and HidP_GetUsages but still no idea how to extract the structure (as described above).
Oh, you have to use GetRawInputData. There is a somewhat crummy example on msdn.
The problem seems to be that each device has it's own structure. There doesn't seem to be a universal way through the win32 api to get the interpretation of the structure.
The combination of
GetRawInputDeviceInfo which gives you a RID_DEVICE_INFO struct
GetRawInputData
GetRawInputBuffer
Seems to get you all the information you can from win32.
After that, you probably need some external source of information (or generated by you), that describes specific fields etc.
I think the headline already explains what I want to know.
Is there a possible way to open and save images with 16-bit with Qt? And I don't mean the 3*8=24bit or 4*8=32bit, what is quite the same as a pure 8-bit image, I mean pure 16-bit for R, G and B.
Contrary to what Patrice says, there is no 16 bits per component format in QImage. The most you can get is QImage::Format_ARGB32 at 8 bits per component. Even if you used 8 bits indexed mode, the color tables do not support more than 8 bits per component. Moreover, the QImageIOHandler class works in terms of QImage, so you cannot create a custom image format plug-in to work with 16 bits per color component, unfortunately.
You can use libpng (png++) for that purpose.
QImage::Format not define pure 16 bit but can define 10 bit.
QImage::Format_A2RGB30_Premultiplied (http://doc.qt.io/qt-5/qimage.html), can use RGB 10 bits per channel (0...1).
But if use QImage::setPixel they still use 8 bit per channel for define pixel from QColor.
As others already mentioned, there is no format with 16 bits per component supported in Qt for now.
However there is a request opened to implement this, with a patch attached: https://bugreports.qt.io/browse/QTBUG-45858
Not sure what is the status of this, and if it will get integrated.
Qt5.13 is supported
here is the example
QImage raw((uchar*)byte.data(), 480, 640, QImage::Format_Grayscale16);
raw.save(QString("%1/depth.raw").arg(fileName));
use the flag QImage::Format_Grayscale16