1920cf75cd
Build a dylib on Darwin
2009-07-12 17:26:10 -07:00
bd7b33e66e
Add the ability to compile libseccure with 'slow' random, i.e. /dev/random instead of /dev/urandom
2009-07-10 14:51:51 -07:00
1aa1382138
Update licensing on the seccure code, moving to LGPL thanks to B. Poettering
2009-07-09 20:21:13 -07:00
270593d49c
Make sure the state and keypair objects are freed post-iterations as well
2009-07-08 13:45:36 -07:00
a8da85fc64
Run loops over reading and encrypting the same sizes of data
2009-07-08 01:18:24 -07:00
4c8353d1e4
Compare memory regions, just to be safe
2009-07-08 01:14:28 -07:00
216f5bc10d
Add a small test binary to encrypt random data *a lot*
2009-07-08 01:08:31 -07:00
a603a31daa
Prevent accidental attempts to re-initialize the secure memory pool
...
Also disabling the termination of the secure memory pool, once terminated
the memory pool cannot be revived for the life of the process.
2009-07-07 16:56:12 -07:00
1f9568b99a
Compile, *then* commit. Stupid semi-colons
2009-07-07 12:22:42 -07:00
b9d319695e
Missing jumps to return early from the function
2009-07-07 12:14:05 -07:00
fe1701e05d
Free the decrypted data object in the test as well
2009-07-07 12:13:21 -07:00
ecfde56e57
Ensure we're not inadvertantly returning a half-allocated ECC_Data struct
2009-07-07 11:57:02 -07:00
c6442de86a
Cleanup the encrypt test, add a couple more assertions to be safe
2009-07-07 11:56:47 -07:00
6994400add
Reduce the number of loops, no need to run as many now that debugging is over
2009-07-06 10:12:24 -07:00
ac24a736af
Add some malloc() error checking
2009-07-06 08:02:17 -07:00
7be6b1b247
Fix a bad cast caught with clang(1)
2009-07-06 06:08:11 -07:00
cf6646f6b9
Add a *lot* more loops to find more leaks
2009-07-06 05:33:48 -07:00
9f65db74b0
Forcefully end the decrypted data string with a null byte
...
Lest we have allocated a segment in non-nullbyted (yes, nullbyted)
memory, and have garbage trailing off the end of the string.
2009-07-06 05:32:52 -07:00
612e112938
Set data member to NULL to make sure we can conditionalize against it later
2009-07-06 04:48:50 -07:00
99dcb2a214
Print out the errno that's running around (for debug)
2009-07-06 04:48:26 -07:00
64ff45319d
Fix a leak underneath seccure's decompress_string() function (used heavily by ecc_encrypt())
...
The gist of what's happening, is that dezerialize_mpi() gives us an (N) MPI which
an affine_point struct's x,y are then assertained with. This N MPI was not
being properly released after P.x and P.y were calculated, resulting in libseccure
exhausting libgcrypt's secure memory pool.
Valgrind results (valgrind --tool=memcheck --leak-check=full --show-reachable=yes ./test_integration -p /integration/keygen_encryptsalot):
Before:
LEAK SUMMARY:
definitely lost: 7,208 bytes in 360 blocks.
indirectly lost: 17,363 bytes in 179 blocks.
possibly lost: 992 bytes in 2 blocks.
still reachable: 16,042 bytes in 85 blocks.
suppressed: 0 bytes in 0 blocks.
After:
LEAK SUMMARY:
definitely lost: 3,232 bytes in 201 blocks.
indirectly lost: 19,628 bytes in 208 blocks.
possibly lost: 992 bytes in 2 blocks.
still reachable: 15,447 bytes in 67 blocks.
suppressed: 0 bytes in 0 blocks.
2009-07-06 04:39:32 -07:00
19d0796a77
Document some of the usage of pointers, etc
2009-07-06 04:37:05 -07:00
469d8c55e4
Set point members to NULL, just in case >_>
2009-07-06 04:36:28 -07:00
927e807510
Print out an error message if our hmac init fails
2009-07-06 04:35:34 -07:00
f23f27e6fc
Add another test case to generate a boatload of keys
2009-07-02 11:29:43 -07:00
e6f02ae624
Print timestamps just for kicks
2009-07-02 10:50:44 -07:00
d9facbd6bb
The behavior of generating different encrypted results is correct
...
Switch the test to make sure we're generating the same length at least
2009-07-02 10:45:51 -07:00
310798b48d
Working on (currently failing) test to verify the ecc_encrypt() results' consistency
2009-07-02 10:33:27 -07:00
e5db992e29
Make sure we NULL the pointers after freeing
2009-07-02 10:33:20 -07:00
c33f0e64ac
Ensure ecc_serialize_private_key() is null-terminating our string
2009-07-01 15:15:33 -07:00
7e65949e7b
Ensure the released pointer gets set to NULL, lest we double free! :(
2009-07-01 14:58:28 -07:00
d58c300738
Separate the deserialize_mpi() and hash_to_exponent() calls
...
hash_to_exponent() should only be called in the keygen case
2009-07-01 11:04:37 -07:00
6e27088af3
Add private key serialization function, hook up to pu_keygen
2009-06-30 23:53:07 -07:00
f89c00de0f
Make sure we're deserializing the mpi if that's what we get, otherwise we should be in keygen mode and be calling hash to exponent
2009-06-30 23:46:36 -07:00
e373c5d622
Initialize pub_butes to zero
2009-06-30 21:13:53 -07:00
ef4e8cd256
Add a couple ecc_free_keypair() calls here and there
2009-06-30 21:11:05 -07:00
ae08078f20
Revert "Revert "Stop passing private key thorugh a SHA-512 block prior to hash_to_exponent()""
...
This reverts commit 78a13c867d
2009-06-30 19:58:13 -07:00
78a13c867d
Revert "Stop passing private key thorugh a SHA-512 block prior to hash_to_exponent()"
...
This reverts commit 704dbf7663
2009-06-30 19:55:10 -07:00
9c38476aa3
Accidentally pruned this at some point causing the ecc_verify() function to fail miserably
2009-06-30 19:45:51 -07:00
553cd2ecf6
Correct warnings, copypasta fail
2009-06-30 19:45:29 -07:00
097b245c2c
Revert "Cleanup mixin_key_and_curve to be more gdb friendly"
...
This reverts commit 75fdb6b19a
2009-06-30 19:40:19 -07:00
704dbf7663
Stop passing private key thorugh a SHA-512 block prior to hash_to_exponent()
...
Breaks compatibility with the seccure binaries, but allows us to get away with
less instructions when creating ECC_KeyPair structures
2009-06-30 19:25:34 -07:00
9b674cae84
Clean up misc use of strlen() here and there, some places it's still needed however
2009-06-30 19:09:57 -07:00
3805ab8891
Use ecc_new_keypair_s() like I should instad of relying on strlen() in ecc_new_keypair()
2009-06-30 19:03:11 -07:00
ba55608cdb
Randomize the right number of bytes, i.e. 384B instead of 384b
2009-06-30 19:02:48 -07:00
54cbf24fb6
Update the DEFAULT_SIG with that generated with the DEFAULT_PUBKEY and DEFAULT_PRIVKEY using seccure-sign
2009-06-30 15:52:38 -07:00
0c9e1422dc
Shuffle pieces around, generate a random buffer and then rely on ecc_new_keypair to generate the appropriate hash for it
2009-06-30 15:46:06 -07:00
22a041ad16
Avoid strlen() since there may be null bytes in here
2009-06-30 15:25:11 -07:00
ee8badddff
Force generating the private key hash, FML
2009-06-30 15:24:58 -07:00
c9bee81a29
Prune now unnecessary defines
2009-06-30 15:24:36 -07:00
R. Tyler Ballance