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.
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 would like to understand the difference between javax.crypto.Mac and javax.crypto.Cipher. Those two classes looks very similar (they have similar methods but those two classes do not inherits from each another).
What's the fundamental difference between those two classes ?
When should I use (or not use) Mac ?
When should I use (or not use) Cipher ?
A Message Authentication Code is for integrity. It computes, on some input message, a kind of "keyed checksum" that depends on the message and on the key. With knowledge of the key, the MAC can be verified to match a given message. Alterations are thus reliably detected.
A Symmetric encryption algorithm is for confidentiality. It transforms a message into an unreadable sequence of bits; the encryption is reversible provided that the decryption key is known.
MAC do not ensure confidentiality; the message is kept as is, plainly readable. Encryption does not ensure integrity; alterations may go undetected. In properly applied cryptography, you need both. (But mind that this "properly" term is big.)
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).
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
Does anybody know some simple authentication and data transfer protocol based on symmetric keys only? Due to memory constraints (kilobytes RAM and ROM) we cant afford asymmetric cryptography and due to closed environment asymmetric cryptography does not increase security of any way.
I am looking for simple symmetric cryptography protocol that can be kept in head and written on one paper sheet. I was looking in EAP-PSK https://www.rfc-editor.org/rfc/rfc4764#page-4 but still think that 2^6 pages is way to much for something simple and secure.
Does anybody know some useful url, paper or idea?
For secrecy, use AES-CBC. For message authentication, use HMAC-SHA256. Use a different key for each.
In both cases, use an existing, validated, timing-attack-free implementation of the cryptographic primitives.
I think you're looking for the Diffie-Hellman key exchange: only requires bignum integer arithmetic (powers, multiplication, and modulus only, at that): http://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange