How can I encode a file using sha256 and c/c++ ???
Thanks!
SHA 256 stands for Secure Hash Algorithm ! It will only produce the hash of a given file . You can't retrieve the original file from a given hash otherwise hash functions are useless.
If you want to do encryption/decryption AES would be a better solution. Everything you need is in OpenSSL.
If you don't know what SHA is for, then you better ask someone who knows this stuff instead of doing it yourself. Even if you use a given library, chances are very high that you will produce snake oil. Security depends on much more than calling some encryption functions.
Related
I have a project where we are supposed to find a sha256 from another sha256.
For example we have
hash1 = "45f1bc22c29626c6db37d483273afbe0f6c434de02fe86229d50c9e71ed144fc"
and we would have to find
hash0 = "5495a885b7f445a198cc5b67a517a0e0536792ab3e7ead18a12c75f8310a9b89"
hash1 is just the hash0 used in a sha256 function.
Initially, I went on to redo every possibility of sha256 but it may do a lot and take a lot of time.
If you have any idea how I could do this, even see if it's possible?
It's impossible, hashes can't be inverted, regardless if they're hashes of hashes or of other content. You could try all the combinations, sure, knowing that the source is a 256-bit sequence, but this is practically prohibitive, although there's always a possibility of 1 out of 2^256 that you guess it at the first try :-)
If i create a SHA-256 has in the terminal i get a nice looking hex hash:
echo -n ChillyWilly | sha256sum
4c74e3994a247dfc31a515721528c78bb6ec09ccdcfd894d09f4aa44131393a8 -
If i try to do the same with the crypt(3) function then i get something entirely different:
const char* what = crypt("ChillyWilly", "$5$");
printf("%s\n", what);
$5$$fQITOGYPwBrwOSpjX1Uhx5Ock/J84zbrqmTtg/SlvMB
It looks like Base64 but it's not.
My assumption is that if the key and salt are equal then i should get the same result. All SHA-256 hashers in the web will generate the same result from the same key/salt combination.
How can i get the same hex hash with the crypt(3) function? I have set the $5$ as instructed on the crypt manpage that should force the crypt function into SHA-256 mode.
I know there are a few similar questions here but they did not seem to contain the correct answers.
Thanks!
While crypt can use SHA-256 when in $5$ mode, they aren't the same thing.
SHA-256 is a hash function, designed to run quickly. But crypt is a key-derivation function intended for hashing passwords. As such, it runs SHA-256 a large number of times (5000 by default) to make it slower and less prone to brute-force attacks. So it will give a different result than a simple SHA-256 use. You can see the details of the algorithm here.
As you saw, crypt also doesn't output the result as hex, but as a Base64-like encoding (not the standard Base64 but based on a similar idea). There's no point in trying to convert to hex if you do this expecting to get the same result as SHA-256.
crypt() will in fact use the same SHA-256 algorithm - but it does not return the hash as you would expect. After computing the hash it does it applies another transformation to the result, as seen here.
So I wouldn't count on using it and getting the same result as sha256sum, since it's built for a different purpose. You might look into using the openssl SHA256 implementation, or something else if you need it to match.
novice to aes. in reading http://en.wikipedia.org/wiki/AES_implementations, I am a bit surprised. I should need just one function
char16 *aes128(char16 key, char16 *secrets, int len);
where char16 is an 8*16=128bit character type. and, presumably, ignoring memory leaks,
assert( bcmp( anystring, aes128(anykey, aes128(anykey, anystring, len), len )==0 );
I am looking over the description of the algorithm on wikipedia, and although I can see myself making enough coding mistakes to take me a few days to debug my own implementation, it does not seem too complex. maybe 100 lines? I did see versions in C#, such as Using AES encryption in C#. that seem themselves almost as long as the algorithm itself. earlier recommendations on stackoverflow mostly recommend the use of individual functions inside larger libraries, but it would be nice to have a go-to function for this task that one could compile into one's code.
so, is AES implementation too complex to be for the faint of heart? or is it reasonably short and simple?
how many lines does a C implementation take? is there a self-contained aes128() C function already in free form somewhere for the taking?
another question: is each block independently encoded? presumably, it would strengthen the encryption if the first block would create a salt that the second block would then use. otoh, this would mean that disk corruption of one block would make every subsequent block undecryptable.
/iaw
You're not seeing a single function like you expect because there are so many options. For example, the block encoding mechanism you described (CBC) is just one option or mode in AES encryption. See here for more information: http://www.heliontech.com/aes_modes_basic.htm
The general rule of thumb in any language is: Don't reinvent something that's already been done and done well. This is especially true in anything related to cryptography.
well using just the AES function is basically insecure as any block X will always be encoded to block Y with key K which is too much information to give an attacker... (according to cryptographers)
so you use some method to change the block cipher at each block. you can use a nonce or Cipher Block Chaining or some other method. but there is a pretty good example on wikipedia (the penguin picture): http://en.wikipedia.org/wiki/Electronic_code_book#Electronic_codebook_.28ECB.29
so in short you can implement AES in one function that is secure (as a block cipher), but it isn't secure if you have data that is longer than 16 bytes.
also AES is fairly complex because of all the round keys... I wouldn't really want to implement it, especially with all of the many good implementations around, but I guess it wouldn't be so bad if you had a good reason to do it.
so in short, to construct a secure stream cipher from a block cipher you need to adopt some strategy to change the effective key along the stream.
ok, so I found a reasonable standalone implementation:
http://www.literatecode.com/aes256
About 400 lines. I will probably use this one.
hope it helps others, too.
I'm writing a C application and I wanna know if there is a way to view .gpg file content (then the encrypted content). The .gpg file in question concerns a simple .txt file that I encrypted.
I know a bit GPGME, it's possible with its function? Or other ways...
EDIT: I thought one thing: if my application use "--armor" option, I've a .gpg file in ASCII mode and not binary...so the .gpg file can be read simply, true? The easiest way...
libgcrypt
This is a general purpose
cryptographic library based on the
code from GnuPG. It provides functions
for all cryptograhic building blocks:
symmetric ciphers (AES, DES, Blowfish,
CAST5, Twofish, Arcfour), hash
algorithms (MD4, MD5, RIPE-MD160,
SHA-1, TIGER-192), MACs (HMAC for all
hash algorithms), public key
algorithms (RSA, ElGamal, DSA), large
integer functions, random numbers and
a lot of supporting functions.
You can use GnuPG Made Easy library, here is a mini howto on using it.
Are there algorithms for putting a digest into the file being digested?
In otherwords, are there algorithms or libraries, or is it even possible to have a hash/digest of a file contained in the file being hashed/digested. This would be handy for obvious reasons, such as built in digests of ISOs. I've tried googling things like "MD5 injection" and "digest in a file of a file." No luck (probably for good reason.)
Not sure if it is even mathematically possible. Seems you'd be able to roll through the file but then you'd have to brute the last bit (assuming the digest was the last thing in the file or object.)
Thanks,
Chenz
It is possible in a limited sense:
Non-cryptographically-secure hashes
You can do this with insecure hashes like the CRC family of checksums.
Maclean's gzip quine
Caspian Maclean created a gzip quine, which decompresses to itself. Since the Gzip format includes a CRC-32 checksum (see the spec here) of the uncompressed data, and the uncompressed data equals the file itself, this file contains its own hash. So it's possible, but Maclean doesn't specify the algorithm he used to generate it:
It's quite simple in theory, but the helper programs I used were on a hard disk that failed, and I haven't set up a new working linux system to run them on yet. Solving the checksum by hand in particular would be very tedious.
Cox's gzip, tar.gz, and ZIP quines
Russ Cox created 3 more quines in Gzip, tar.gz, and ZIP formats, and wrote up in detail how he created them in an excellent article. The article covers how he embedded the checksum: brute force—
The second obstacle is that zip archives (and gzip files) record a CRC32 checksum of the uncompressed data. Since the uncompressed data is the zip archive, the data being checksummed includes the checksum itself. So we need to find a value x such that writing x into the checksum field causes the file to checksum to x. Recursion strikes back.
The CRC32 checksum computation interprets the entire file as a big number and computes the remainder when you divide that number by a specific constant using a specific kind of division. We could go through the effort of setting up the appropriate equations and solving for x. But frankly, we've already solved one nasty recursive puzzle today, and enough is enough. There are only four billion possibilities for x: we can write a program to try each in turn, until it finds one that works.
He also provides the code that generated the files.
(See also Zip-file that contains nothing but itself?)
Cryptographically-secure digests
With a cryptographically-secure hash function, this shouldn't be possible without either breaking the hash function (particularly, a secure digest should make it "infeasible to generate a message that has a given hash"), or applying brute force.
But these hashes are much longer than 32 bits, precisely in order to deter that sort of attack. So you can write a brute-force algorithm to do this, but unless you're extremely lucky you shouldn't expect it to finish before the universe ends.
MD5 is broken, so it might be easier
The MD5 algorithm is seriously broken, and a chosen-prefix collision attack is already practical (as used in the Flame malware's forged certificate; see http://www.cwi.nl/news/2012/cwi-cryptanalist-discovers-new-cryptographic-attack-variant-in-flame-spy-malware, http://arstechnica.com/security/2012/06/flame-crypto-breakthrough/). I don't know of what you want having actually been done, but there's a good chance it's possible. It's probably an open research question.
For example, this could be done using a chosen-prefix preimage attack, choosing the prefix equal to the desired hash, so that the hash would be embedded in the file. A
preimage attack is more difficult than collision attacks, but there has been some progress towards it. See Does any published research indicate that preimage attacks on MD5 are imminent?.
It might also be possible to find a fixed point for MD5; inserting a digest is essentially the same problem. For discussion, see md5sum a file that contain the sum itself?.
Related questions:
Is there any x for which SHA1(x) equals x?
Is a hash result ever the same as the source value?
The only way to do this is if you define your file format so the hash only applies to the part of the file that doesn't contain the hash.
However, including the hash inside a file (like built into an ISO) defeats the whole security benefit of the hash. You need to get the hash from a different channel and compare it with your file.
No, because that would mean that the hash would have to be a hash of itself, which is not possible.