Working with travis-ci, and they provide a default public key it seems but only the fingerprint is available (1b:fe:b0:e4:dd:94:ba:46:6a:91:23:60:4a:a7:d0:46).
I know this is generally a processed version (md5 digest with base64 usually) of the public key - is it possible to reverse?
I understand hashes in cryptography are only valuable because they generally cannot be reversed, but since md5 has been broken...
Considering what fingerprinting is, no.
As mentioned here
Fingerprint hashing is merging fingerprint recognition and cryptographic methods. The aim is to perform a recognition using fingerprint while, at the same time, hiding the private information related to the fingerprint, thus enabling public fingerprint templates.
It is a one-way hash function, even with md5:
A one-way hash function, also known as a message digest, fingerprint or compression function, is a mathematical function which takes a variable-length input string and converts it into a fixed-length binary sequence.
Related
I'm trying to optimize my signature and verification scheme for an embedded device and I'm finding race conditions at just 0.5s/verification. Instead of making the device compute the SHA-256 hash of the data, could I just use an AES encryption and sign that with PSS to accelerate the process, or does it need to be a hashing algorithm?
If you’re asking if the concept could work: sure. You could pigeon hole the tag as a 128-bit hash output and, provided you’re calling API that accepts the pre-computed hash everything would work (provided you told the PSS operations they were using a 128 but hash algorithm).
But no one else would be able to verify your signature, because that’s not a predefined way of doing RSASSA-PSS. And you’d have a “public only” verification problem… the only way someone can know if the tag matched the data was to also have the encryption key, so you would have to embed the key and nonce in the signature parameters (a really bad idea) or just be a private/application protocol.
So, it could be done, but it won’t interoperate, and it’s almost guaranteed never to be a standard because it can’t be used by implementations that don’t accept pre-computed hashes (without forcing the scheme to plaintext transport the content encryption key).
In general, RSA-PSS requires a hash algorithm for the mask generation function and other operations, so it's doubtful that you could actually make RSA-PSS work in any functional way with something that is not a hash algorithm.
The idea you're proposing is also likely insecure, so even if you could get it to work, it wouldn't be effective as a signature scheme, since it could probably be forged. That's because AES, unlike a hash function, allows users to invert the operation (that is, decrypt), so an attacker who knows the key (which, if you hard-code it, they do) can likely create arbitrary messages to sign.
For a secure digital signature, you really need a secure hash algorithm, which means that you need something like SHA-2, SHA-3, or similar (MD5 and SHA-1 are not secure and should not be used). If possible, I would investigate a possibly more performant SHA-256 implementation here. You could also try the hash algorithm BLAKE2s, which is both cryptographically secure and much faster in software than SHA-256, and may meet your needs better.
I am attempting to use RSA public key encryption to encrypt a AES+CBC key over a network, however I'm having trouble finding the right tools or setup in order to achieve my goal.
I've been looking over at the Transforms API, which is perfectly capable of using RSA for signing/verifying data, but have thus far been unable to figure out how to utilize it for encrypting itself.
My question is therefore as follows: Am I stuck with libcrypto/OpenSSL or is what I'm trying to accomplish actually still possible with the API? The goal being using `SecEncryptTransformCreate' etc. to use RSA rather than AES/Symmetric encryption.
SecEncryptTransformCreate seems to support both PKCS#1 (v1.5, although it doesn't say) and OAEP padding, according to the API. I've also seen some samples for the (more secure) OAEP padding.
Again, the API does not seem to specify RSA anywhere, but PKCS#1 padding and OAEP padding are RSA specific encryption schemes.
So you seem to be looking at the correct API to use. Note that to encrypt larger amounts of plain text you should be using hybrid encryption (both AES and RSA).
Team,
I would like to have asymmetric encryption using AES algorithm for iPhone application using Objective C.
I have widely seen symmetric encryption using AES, so im not sure about the support for asymmetric encryption with AES. Kindly suggest me on this.
AES is a symmetric cipher. It can't simply be used an an asymmetric (i.e., public-key) capacity.
I am guessing the reason for your question is the issue of key exchange - such that you can establish an AES-encrypted connection without having to rely on a pre-shared key.
Numerous valid approaches exist, but I'll just hit on two:
Take a look at or Diffie-Hellman. You can get both sides of a connection to agree on a key without actually having to exchange that key. http://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange
RSA. I'm a fan of Botan. It's free. It works. You can generate public/private key pairs on both sides, exchange the public keys, then securely exchange private keys, and then start AES. http://botan.randombit.net/pubkey.html
As always, this advice needs to be accompanied with a warning: it's very easy to do this incorrectly and largely (or entirely) thwart your security efforts. Tread carefully.
Up to now, I thought that if I have RSA-encrypted data, this data would be easily exchangable between most platforms (.net, java, pc, unix..), because of the commonly used algorithm.
Through investigating for another questions I had, I'm now confused. I have found even between MS-implementations differences (some provider reverse the resulting byte-array). Moreover the padding seems not to follow a standardization.
Can someone with experience in cross platform cryptography give a statement, if RSA-encoded data is relatively simple exchangable (with some obvious pitfalls) or if this is a headache?
Note that RSA encryption is normally not used by itself, but in combination with a symmetric encryption algorithm.
So, to make sure to be interoperable, you need to make sure that:
Both sides use the same padding scheme for RSA (e.g. the one originally defined in PKCS#1 v1.5, or OAEP). (That does not mean that the padding has to be deterministic, just that the decrypter know which bits of the decrypted text was padding and which were the original message).
Both sides use the same format for their messages (e.g. the one in PKCS#7 or its successors).
Both sides use the same symmetric algorithm (e.g. AES-128), mode of operation (e.g. CBC) and block cipher padding scheme (e.g. PKCS#5-padding).
The encrypting party must use the public key corresponding to the private key used by the decrypting party.
The simple answer to your question is no, the cryptographic algorithm itself does not specify how to store or transmit bytes between implementations to ensure interoperability. For that you must use a standard format or protocol that gives these instructions down to the bit level. For example, in Paulo answer he talks about PKCS#7 and PKCS#1. These in turn rely on the DER-encoding rules of ASN.1 that specify exactly how to covert the big integer pieces of RSA into an unambigous sequence of bytes and back again.
Say I have some data and a password, and I want to encrypt the data in such a way that it can only be recovered with the right password.
How does this technically work (i.e. how to implement this)? I often hear people use bitshifting for encryption, but how do you base that on a password? How does password-based encryption work?
An example is Mac OS X FileVault
Thanks.
If you give sample code, preferably in C, Objective-C or pseudocode.
For (symmetric) encryption you need a secret key for encryption and decryption.
Usually, the password you supply is used as the source of this key. For various security reasons, the password is not (and often cannot, due to requirements of the cipher used) directly used as the key. Instead, a key derivation function is used to generate the key from the password.
This is why passwords for encryption must be long and fairly random: Otherwise the resulting key will only come from a very small subset of possible keys, and these can then simply all be tried, thus brute-forcing the encryption.
As to code examples, there are several possibilities:
look at the source code of a crypto library, such as OpenSSL
look at the source code of a program that implements encryption, such as GnuPG
google some sample source code for a simple encryption algorithm, or a key derivation function, and try to understand it
This depends on what you want to learn.
You'll need to look to other resources for a deep explanation, as this question is extremely broad.
Speaking generally: you use a password as a "seed" for an encryption key, as sleske pointed out. Then you use this key to apply a two-way encryption algorithm (i.e. one that can be applied once to encrypt and again to decrypt). When you apply the algorithm to a piece of data, it becomes encrypted in such a way that you could never get the data back out again without using the same key, and you can't practically produce the same key without having the same password as a seed.
If you're interested in crypto, read Applied Cryptography by Bruce Schneier. Excellent read, lots of examples. It goes through many different cryptography types.
An easy way, but not exactly secure, is to rotate each byte by a number determined by the password. You can use a hash code from a string, or count the number of characters, or whatever for the number.
What you are probably thinking of, though, is public key encryption. Here is a link to a document that will tell you the math for it - you'll have to work out the implementation details yourself, but it's not that hard once you understand the math.
http://mathaware.org/mam/06/Kaliski.pdf
The basic building block of most block ciphers is a construction called a Feistel Network. It's reasonably easy to understand.
Stream ciphers are even simpler - they're essentially just pseudo-random number generators, albeit with some important security properties, where the initial internal state is derived from the key.
Password based encryption IS symmetric. The input usually consists of a salt in addition to the password. FooBabel has a cool app where you can play around with this... currently they hard code the Salt to an array of eight bytes (zero to seven) for simplicity. I put in a request to see that they let users input the salt. Anyway, here it is - PBECrypto