Hello all,
I've been working for quite some time trying to convert a linux library, using libgcrypt 1.1.12, into something for Windows. After a lot of fumbling with Visual C++ and interference from other projects, I did manage to use the LIB.EXE tool to create a static Windows library out of the .dsp file I got from Timo. Thanks Timo! Then I successfully built my Windows library (.lib) for a small subset of public-key functions plus some error handling.
Using a test program with a loop that simply encrypts a buffer, writes it to disk, reads it back and decrypts it to make sure the numbers match, I am having problems with the creation of the sexp from the encrypted file on disk... Is anyone aware of any issues that would stop reading the file before the end... Can an encrypted file contain an <eof> character?
The files being saved (and those successfully re-read) are about 155 bytes,
>String from disk:
>(7:enc-val(3:rsa(1:a128:u?+Tü?+èKb«??.F
>retSize = 155 <-----------------same as original size
>
>gcry_sexp_dump:
>[open]
> [data="enc-val"]
> [open]
> [data="rsa"]
> [open]
> [data="a"]
> [data="u\x0e\xbdT\x81\x1e\xc5\x8aKb\xae\x16\x05.F\0{\xf2\xf0#,\x8aND\xc9{\xbc\xee\0\xc4<\xfd9^5&}\xacc/\xb0Q\xfb\xe9\x125n\xc4\xb0/\xe7\x143\xder\x92\x9b\xef\x9e7\x1b\x1ey|2\x05\xd8/=J\xc4\xfe\xc5\xd6r\xa3\x89\xcd|\x0e\x93\xa0|T\xd9\x81R\xa6w5\x117\xe6\xbdZM!\x121u\xa1;\x0e`%\xd0\xe9\xcb\x9a\xdc$\xbc\x8bny\xea\0C\x9bP\xbc\xd4\x8dZ\x83\xb14\xf6"]
> [close]
> [close]
>[close]
>
>7u11A6781F520b32 <---> 7u11A6781F520b32 (MATCH)
but the failing files are less than that - sometimes substantially less...
>String from disk:
>(7:enc-val(3:rsa(1:a129:
>retSize = 43 <---- or 153, 129, 81, 140, etc...
no apparent pattern,
but always < original file
>
>grcy_sexp_dump:
>[nil]
>constructing data block failed. Aborting function...
>
>8Q1271a36n5R44Y7 <---> (NO MATCH)
Is there a way to put a wrapper on the file, or is there some sort of "ascii-armoring" or similar file I/O-safe format I can write these files in to fix this problem? Thanks for any ideas.
--
Tony Warren
Prairie Systems, Inc.
garbaj@prairiesys.com
<}-:
I've been working for quite some time trying to convert a linux library, using libgcrypt 1.1.12, into something for Windows. After a lot of fumbling with Visual C++ and interference from other projects, I did manage to use the LIB.EXE tool to create a static Windows library out of the .dsp file I got from Timo. Thanks Timo! Then I successfully built my Windows library (.lib) for a small subset of public-key functions plus some error handling.
Using a test program with a loop that simply encrypts a buffer, writes it to disk, reads it back and decrypts it to make sure the numbers match, I am having problems with the creation of the sexp from the encrypted file on disk... Is anyone aware of any issues that would stop reading the file before the end... Can an encrypted file contain an <eof> character?
The files being saved (and those successfully re-read) are about 155 bytes,
>String from disk:
>(7:enc-val(3:rsa(1:a128:u?+Tü?+èKb«??.F
>retSize = 155 <-----------------same as original size
>
>gcry_sexp_dump:
>[open]
> [data="enc-val"]
> [open]
> [data="rsa"]
> [open]
> [data="a"]
> [data="u\x0e\xbdT\x81\x1e\xc5\x8aKb\xae\x16\x05.F\0{\xf2\xf0#,\x8aND\xc9{\xbc\xee\0\xc4<\xfd9^5&}\xacc/\xb0Q\xfb\xe9\x125n\xc4\xb0/\xe7\x143\xder\x92\x9b\xef\x9e7\x1b\x1ey|2\x05\xd8/=J\xc4\xfe\xc5\xd6r\xa3\x89\xcd|\x0e\x93\xa0|T\xd9\x81R\xa6w5\x117\xe6\xbdZM!\x121u\xa1;\x0e`%\xd0\xe9\xcb\x9a\xdc$\xbc\x8bny\xea\0C\x9bP\xbc\xd4\x8dZ\x83\xb14\xf6"]
> [close]
> [close]
>[close]
>
>7u11A6781F520b32 <---> 7u11A6781F520b32 (MATCH)
but the failing files are less than that - sometimes substantially less...
>String from disk:
>(7:enc-val(3:rsa(1:a129:
>retSize = 43 <---- or 153, 129, 81, 140, etc...
no apparent pattern,
but always < original file
>
>grcy_sexp_dump:
>[nil]
>constructing data block failed. Aborting function...
>
>8Q1271a36n5R44Y7 <---> (NO MATCH)
Is there a way to put a wrapper on the file, or is there some sort of "ascii-armoring" or similar file I/O-safe format I can write these files in to fix this problem? Thanks for any ideas.
--
Tony Warren
Prairie Systems, Inc.
garbaj@prairiesys.com
<}-: