Generating a random UUID in C - c

How would I go about generating an entropy-based UUID in C and storing it as a string (char pointer)?
I'm hoping that there is an easy way to do this internally, but system("uuidgen -r") will work if not.

This functionality is provided by libuuid. (Packages libuuid1 and uuid-dev on Debian.)
This is a simple program that generates an entropy-based (random) UUID and writes it to stdout, then exits with status 0.
/* For malloc() */
#include <stdlib.h>
/* For puts()/printf() */
#include <stdio.h>
/* For uuid_generate() and uuid_unparse() */
#include <uuid/uuid.h>
/* Uncomment to always generate capital UUIDs. */
//#define capitaluuid true
/* Uncomment to always generate lower-case UUIDs. */
//#define lowercaseuuid true
/*
* Don't uncomment either if you don't care (the case of the letters
* in the 'unparsed' UUID will depend on your system's locale).
*/
int main(void) {
uuid_t binuuid;
/*
* Generate a UUID. We're not done yet, though,
* for the UUID generated is in binary format
* (hence the variable name). We must 'unparse'
* binuuid to get a usable 36-character string.
*/
uuid_generate_random(binuuid);
/*
* uuid_unparse() doesn't allocate memory for itself, so do that with
* malloc(). 37 is the length of a UUID (36 characters), plus '\0'.
*/
char *uuid = malloc(37);
#ifdef capitaluuid
/* Produces a UUID string at uuid consisting of capital letters. */
uuid_unparse_upper(binuuid, uuid);
#elif lowercaseuuid
/* Produces a UUID string at uuid consisting of lower-case letters. */
uuid_unparse_lower(binuuid, uuid);
#else
/*
* Produces a UUID string at uuid consisting of letters
* whose case depends on the system's locale.
*/
uuid_unparse(binuuid, uuid);
#endif
// Equivalent of printf("%s\n", uuid); - just my personal preference
puts(uuid);
return 0;
}
uuid_unparse() doesn't allocate it's own memory; to avoid a segmentation fault upon execution you must do that with manually with uuid = malloc(37); (you can also store the UUID in a char array of that length: char uuid[37];). Make sure to compile with -luuid so that the linker knows that uuid_generate_random() and uuid_unparse() are defined in libuuid.

Since everyone is saying to use a library, I figured I'd write a fast-and-dirty-C-only version using C's rand(). Make sure to call srand somewhere so the random UUIDs are actually somewhat random.
There's no guarantees that it won't generate two identical UUIDs, and there's no guarantee this meets whatever standard UUIDs have. As far as I know, they're just random hexadecimal strings with dashes between blocks. Also, this isn't multithreading safe.
char* gen_uuid() {
char v[] = {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f'};
//3fb17ebc-bc38-4939-bc8b-74f2443281d4
//8 dash 4 dash 4 dash 4 dash 12
static char buf[37] = {0};
//gen random for all spaces because lazy
for(int i = 0; i < 36; ++i) {
buf[i] = v[rand()%16];
}
//put dashes in place
buf[8] = '-';
buf[13] = '-';
buf[18] = '-';
buf[23] = '-';
//needs end byte
buf[36] = '\0';
return buf;
}

On Linux, you can use <uuid/uuid.h>, which for me on Ubuntu 20.x is located in /usr/include/uuid/.
/* uuid.c
*
* Defines function uuid
*
* Print a universally unique identifer, created using Linux uuid_generate.
*
*
* Compile
*
* gcc uuid.c -o uuid -luuid -Wall -g
*
*
* Run
*
* ./uuid
*
*
* Debug
*
* gdb uuid
* b main
* r
*
*/
#include <stdlib.h>
#include <stdio.h>
#include <uuid/uuid.h>
char* uuid(char out[UUID_STR_LEN]){
uuid_t b;
uuid_generate(b);
uuid_unparse_lower(b, out);
return out;
}
int main(){
char out[UUID_STR_LEN]={0};
puts(uuid(out));
return EXIT_SUCCESS;
}

Related

Unable to retrieve data area value using QXXRTVDA and brace-initialized values

I was trying to do simple data area value retrieval using C source from here:
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/rtref/qxxrtvd.htm
And... the code failed to do certain retrieval.
Here is the code:
typedef struct _DTAA_NAME_T {
char dtaa_name[10]; /* name of data area */
char dtaa_lib[10]; /* library that contains data area */
}_DTAA_NAME_T;
and
#include <stdio.h>
#include <xxdtaa.h>
#define DATA_AREA_LENGTH 30
#define START 6
#define LENGTH 7
int main(void)
{
char uda_area[DATA_AREA_LENGTH];
/* Retrieve data from user-defined data area currently in MYLIB */
_DTAA_NAME_T dtaname = {"USRDDA ", "MYLIB "};
/* Use the function to retrieve some data into uda_area. */
QXXRTVDA(dtaname,START,LENGTH,uda_area);
/* Print the contents of the retrieved subset. */
printf("uda_area contains %7.7s\n",uda_area);
}
There are several problems in this brace-intialized values:
_DTAA_NAME_T dtaname = {"USRDDA ", "MYLIB "};
Values can not get initialized with 10 characters value - only 9 chars + null byte.
Initializing values with 10 characters will lead to compilation error.
Initializing it with anything less than 10 characters will lead to null byte appending thus the QXXRTVDA will not find any values as soon as there's no such library with null byte ending.
The workaround I've found is to avoid brace-initialization and initialize values with direct bytes copying:
#include <stdio.h>
#include <xxdtaa.h>
#include <QSYSINC/MIH/CPYBLA>
#define DATA_AREA_LENGTH 30
#define START 6
#define LENGTH 7
int main(void)
{
char uda_area[DATA_AREA_LENGTH];
_DTAA_NAME_T dtaara;
memset( &dtaara, ' ', sizeof(dtaara));
cpybla( dtaara.dtaa_name, "USRDDA", 6);
cpybla( dtaara.dtaa_lib, "MYLIB", 5);
/* Use the function to retrieve some data into uda_area. */
QXXRTVDA(dtaname,START,LENGTH,uda_area);
/* Print the contents of the retrieved subset. */
printf("uda_area contains %7.7s\n",uda_area);
}
Hope this helps somebody not to waste time on such a basic thing.
The null-termation byte is only used to initialize the array if there is room for it.
#include <xxdtaa.h>
main()
{
_DTAA_NAME_T dtaara = {"ABCDEFGHIJ", "KLMNOPQRST"};
return;
}
In debug:
EVAL dtaara:x 20
00000 C1C2C3C4 C5C6C7C8 C9D1D2D3 D4D5D6D7 - ABCDEFGHIJKLMNOP
00010 D8D9E2E3 ........ ........ ........ - QRST............

How to store keys of associative array in C implemented via hcreate/hsearch by value (not by reference)?

Using associative arrays implented via the POSIX hcreate/hsearch functions (as described here, I struggled some unexpected behaviour finding keys I've never entered or the other way around.
I tracked it down to some instance of store-by-reference-instead-of-value.
This was surprising to me, since in the example uses string literals as keys:
store("red", 0xff0000);
store("orange", 0x123456); /* Insert wrong value! */
store("green", 0x008000);
store("blue", 0x0000ff);
store("white", 0xffffff);
store("black", 0x000000);
store("orange", 0xffa500); /* Replace with correct value. */
Here is an MWE that shows my problem:
#include <inttypes.h> /* intptr_t */
#include <search.h> /* hcreate(), hsearch() */
#include <stdio.h> /* perror() */
#include <stdlib.h> /* exit() */
#include <string.h> /* strcpy() */
void exit_with_error(const char* error_message){
perror(error_message);
exit(EXIT_FAILURE);
}
int fetch(const char* key, intptr_t* value){
ENTRY e,*p;
e.key=(char*)key;
p=hsearch(e, FIND);
if(!p) return 0;
*value=(intptr_t)p->data;
return 1;
}
void store(const char *key, intptr_t value){
ENTRY e,*p;
e.key=(char*)key;
p = hsearch(e, ENTER);
if(!p) exit_with_error("hash full");
p->data = (void *)value;
}
void main(){
char a[4]="foo";
char b[4]="bar";
char c[4]="";
intptr_t x=NULL;
if(!hcreate(50)) exit_with_error("no hash");
store(a,1); /* a --> 1 */
strcpy(c,a); /* remember a */
strcpy(a,b); /* set a to b */
store(a,-1); /* b --> -1 */
strcpy(a,c); /* reset a */
if(fetch(a,&x)&&x==1) puts("a is here.");
if(!fetch(b,&x)) puts("b is not.");
strcpy(a,b); printf("But if we adjust a to match b");
if(fetch(a,&x)&&x==-1&&fetch(b,&x)&&x==-1) puts(", we find both.");
exit(EXIT_SUCCESS);
}
Compiling and executing above C code results in the following output:
a is here.
b is not.
But if we adjust a to match b, we find both.
I will need to read a file and store a a large number of string:int pairs and then I will need to read a second file to check an even larger number of strings for previously stored values.
I don't see how this would be possible if keys are compared by reference.
How can I change my associative array implementation to store keys by value?
And if that's not possible, how can I work around that problem given the above use case?
edit:
This question just deals with keys entered but not found.
The opposite problem also appears and is described in detail in this question.
edit:
It turned out that store() needs to strdup() key to fix this and another problem.
I found out that by using the same variable for storage & lookup, I can actually retrieve all the values in the array:
void main(){
char a[4]="foo";
char b[4]="bar";
char c[4]="baz";
char t[4]="";
intptr_t x=NULL;
if(!hcreate(50)) exit_with_error("no hash");
strcpy(t,a); store(t, 1); /* a --> 1 */
strcpy(t,b); store(t,-1); /* b --> -1 */
strcpy(t,c); store(t, 0); /* c --> 0 */
if(!fetch(a,&x)) puts("a is not here.");
if(!fetch(b,&x)) puts("Neither is b.");
if( fetch(c,&x)) puts("c is in (and equal to t).");
strcpy(t,a); if(fetch(t,&x)&&x== 1) puts("t can retrieve a.");
strcpy(t,b); if(fetch(t,&x)&&x==-1) puts("It also finds b.");
strcpy(t,c); if(fetch(t,&x)&&x== 0) puts("And as expected c.");
exit(EXIT_SUCCESS);
}
This results in the following output:
a is not here.
Neither is b.
c is in (and equal to t).
t can retrieve a.
It also finds b.
And as expected c.
However, I still don't understand why this is happening.
Somehow it seems the key needs to be at the same location (reference) and contain the same content (value) to be found.

Computing websocket Sec-WebSocket-Accept value using libtomcrypt

RFC6455 specifies a method of computing the Sec-WebSocket-Accept response header from the value of the Sec-WebSocket-Key header. This method is based on SHA-1 hashing and Base64-encoding the result.
How can I implement this method in plain C using libtomcrypt for SHA-1 and Base64?
Note: This question intentionally does not show any effort because I immediately answered it myself. See below for my effort.
Here's a full compilable example that uses only libtomcrypt without any dynamic memory allocation and successfully computes the reference example from RFC6455:
//This file is licensed under CC0 1.0 Universal (public domain)
//Compile like this: gcc -o wsencodetest wsencodetest.c -ltomcrypt
#include <stdio.h>
#include <string.h>
#include <stdint.h>
#include <ctype.h>
#include <tomcrypt.h>
#define SHA1_HASHSIZE 20
//Magic GUID as defined in RFC6455 section 1.3
static const char magicGUID[] = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";
/**
* Compute the value of the Sec-WebSocket-Accept response header
* from the value of the Sec-WebSocket-Key header.
* #param key The whitespace or NUL terminated Sec-WebSocket-Key value
* #param out Where to store the base64-encoded output. Must provide 29 bytes of memory.
* The 29 bytes starting at out contain the resulting value (plus a terminating NUL byte)
*/
void computeWebsocketSecAccept(const char* key, char* dst) {
/**
* Determine start & length of key minus leading/trailing whitespace
* See RFC6455 section 1.3
*/
//Skip leading whitespace
while(isspace(*key)) {
key++;
}
//Determine key size.
size_t keySize = 0;
while(!isspace(key[keySize]) && key[keySize] != 0) {
keySize++;
}
//Compute SHA1 hash. See RFC6455 section 1.3
char hashOut[SHA1_HASHSIZE];
hash_state md;
sha1_desc.init(&md);
sha1_desc.process(&md, key, keySize);
sha1_desc.process(&md, magicGUID, sizeof(magicGUID));
sha1_desc.done(&md, hashOut);
//Encode hash to output buffer
size_t outlen = 29; //We know the output is 28 in size
base64_encode(hashOut, SHA1_HASHSIZE, dst, &outlen);
}
/**
* Usage example
*/
int main(int argc, char** argv) {
//Whitespace needs to be removed according to RFC6455
//Example from RFC6455
const char* key = " dGhlIHNhbXBsZSBub25jZQ== ";
char buf[29];
//Perform computation
computeWebsocketSecAccept(key, buf);
//Should print s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
printf("%s\n", buf);
}

The Vigenere encryption

I have written some code, and the Vigenere encryption is used in it. This is a simple program for encrypting/decrypting any files.
#include<stdio.h>
/*
LANGUAGE: C.
STANDARD: C89.
ABOUT PROGRAM:
This is a simple program for encrypting/decrypting any files.
The size of source file coincide with size of result file.
For encryption of file are use any string key. For decrypting,
you must to use the same key, which was used for encryption.
NOTES:
The Vigenere encryption are used in it.
Info at the site: http://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher.
This simple algorithm is often used at commercial products. The
Vigenere's algorithm are using a string key, and 'XOR' for
encrypting/decrypting information.
WARNING!
The use of this method, doesn't give 100% of a warranty
for protection of your information. Don't create the keys,
consisting of identical characters, for example" "aaaaa",
"zzz", "xxxx" e.t.c. - it is very feeble protection!
Don't forget your encrypting keys... :)
SYNTAX OF USING:
vigenere StringKey SourceFileName ResultFileName
where:
vigenere - program name;
StringKey - string key for encrypting/decrypting;
SourceFileName - source file name;
ResultFileName - result file name;
EXAMPLE OF USING:
vigenere "G5$hj4*df7f3+x" "c:\temp\source.txt" "c:\temp\result.txt"
*/
int main(int argc, char *args[]){
/****************************************************/
/* All variables must be defined on top in function, otherwise
some compilers can't compile this code (for example - MS
Visual Studio 2012. */
char ch; /* The next char for encrypting/decrypting. */
char *x; /* String key. */
FILE *srcFile; /* Source file. */
FILE *trgFile; /* Result file. */
/****************************************************/
/* The first argument always is a program file name. */
if (4 != argc)
return 1; /* Invalid arguments count. */
if (!*args[1] || !*args[2] || !*args[3])
return 2; /* Contains the empty argument. */
x = args[1];
if ((srcFile = fopen(args[2], "rb")) != NULL){
if ((trgFile = fopen(args[3], "wb")) != NULL){
while((ch = getc(srcFile)) != EOF){
if(!*x++)
x = args[1];
putc((ch ^= *x), trgFile);
}
fclose(trgFile);
}
else
return 4; /* Result file wasn't created. */
fclose(srcFile);
}
else
return 3; /* Source file wasn't opened. */
return 0; /* Successful operation. */
}
But this code does not always work well. I don't understand why it occurs. I do XOR for each byte. I have tested this code on such TXT files. Where is my mistake?
char ch;
/* ... */
while((ch = getc(srcFile)) != EOF)
ch must be an int. EOF is defined as a negative int.
In addition to ouah's answer, the pointer value increment looks off.
your if statement, if(!*x++), is bad for two reasons:
By doing an increment before the actual XOR operation, you're skipping the first character of your key in the initial loop.
There's no point in incrementing the pointer if you already reach the null-terminating character.
The better code would be:
while((ch = getc(srcFile)) != EOF){
putc((ch ^= *x), trgFile);
if(!*++x)
x = args[1];
}

C Libmcrypt cannot encrypt/decrypt successfully

I am working with libmcrypt in c and attempting to implement a simple test of encryption and decryption using rijndael-256 as the algorithm of choice. I have mirrored this test implementation pretty closely to the man pages examples with rijndael as opposed to their chosen algorithms. When compiled with the string gcc -o encryption_test main.c -lmcrypt, the following source code produces output similar to:
The encrypted message buffer contains j��A��8 �qj��%`��jh���=ZЁ�j
The original string was ��m"�C��D�����Y�G�v6��s��zh�
Obviously, the decryption part is failing, but as it is just a single function call it leads me to believe the encryption scheme is not behaving correctly as well. I have several questions for the libmcrypt gurus out there if you could point me in the right direction.
First, what is causing this code to produce this broken output?
Second, when dealing with mandatory fixed-sizes such as the key size and block-size, for example a 256-bit key does the function expect 32-bytes of key + a trailing null byte, 31-bytes of key + a trailing null byte, or 32-bytes of key with the 33rd byte being irrelevant? The same question holds true for block-size as well.
Lastly, one of the examples I noted used mhash to generate a hash of the key-text to supply to the encryption call, this is of course preferable but it was commented out and linking in mhash seems to fail. What is the accepted way of handling this type of key-conversion when working with libmcrypt? I have chosen to leave any such complexities out as to prevent further complicating already broken code, but I would like to incorporate this into the final design. Below is the source code in question:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <mcrypt.h>
int main(int argc, char *argv[])
{
MCRYPT mfd;
char *key;
char *plaintext;
char *IV;
unsigned char *message, *buffered_message, *ptr;
int i, blocks, key_size = 32, block_size = 32;
message = "Test Message";
/** Buffer message for encryption */
blocks = (int) (strlen(message) / block_size) + 1;
buffered_message = calloc(1, (blocks * block_size));
key = calloc(1, key_size);
strcpy(key, "&*GHLKPK7G1SD4CF%6HJ0(IV#X6f0(PK");
mfd = mcrypt_module_open(MCRYPT_RIJNDAEL_256, NULL, "cbc", NULL);
if(mfd == MCRYPT_FAILED)
{
printf("Mcrypt module open failed.\n");
return 1;
}
/** Generate random IV */
srand(time(0));
IV = malloc(mcrypt_enc_get_iv_size(mfd));
for(i = 0; i < mcrypt_enc_get_iv_size(mfd); i++)
{
IV[i] = rand();
}
/** Initialize cipher with key and IV */
i = mcrypt_generic_init(mfd, key, key_size, IV);
if(i < 0)
{
mcrypt_perror(i);
return 1;
}
strncpy(buffered_message, message, strlen(message));
mcrypt_generic(mfd, buffered_message, block_size);
printf("The encrypted message buffer contains %s\n", buffered_message);
mdecrypt_generic(mfd, buffered_message, block_size);
printf("The original string was %s\n", buffered_message);
mcrypt_generic_deinit(mfd);
mcrypt_module_close(mfd);
return 0;
}
You need to re-initialize the descriptor mfd for decryption, you cannot use the same descriptor for both encryption and decryption.

Resources