When I apply Crypt::encrypt(1) I'm getting this encrypted string:
eyJpdiI6IlBoQnliQkZkb0NPT1g5NG9FbkpqV2hLa3ZLUnlWSEFRMEZwM2YxTEdNVk09IiwidmFsdWUiOiJ0N0kyWmZvRWVETzE3WTJWVU5DS1ZpTVFYTGpXNHQxT2YyQWdsMFgxK0xvPSIsIm1hYyI6IjAzMjAzNzdhNzZmYmZiZDVkZGJkMjM5MWY5NjhkNzJjMWFhMzNiYmYyZDJkODNlMmFkODcyNzdhYTE3ZjFkODMifQ==
Is it possible to make string shorter (4-5 times shorter) in Laravel, using the same two-way encryption?
What you want to do, instead of encrypting uri portion is obfuscate it. For example, one of the great libraries for php is Hashids
Related
I've been playing around with php mcrypt over the weekend with AES used to encrypt text strings with a key. Later I worked up a tiny php tool to encrypt / decrypt your strings with AES/mcrypt now when the key is "wrong" and the text doesn't get decrypted, you end up with what I think is binary from what I've read around (http://i.imgur.com/jF8cZMZ.png), is there anyway in PHP to check if the variable holds binary or a properly decoded string?
My apologies if the title and the intro are a bit misleading.
When you encrypt text and then try to decrypt it, you will get the same text, but when you try to decrypt random data, there is a small chance that the result will be text (decreasing with length of data). You haven't specified what kind of data we are talking about, but determining if the decryption is successful by applying a heuristic is a bad idea. It is slow and may lead to false positives.
You should have a checksum or something like that to determine if the decrypted result is valid. This could be easily done by running sha1 on the plaintext data, prepend the result to the text and encrypt it as a whole. When you decrypt it, you can split (sha1 output has a fixed size, so you know where to split) the resulting string run sha1 on the text part and compare with the hash part. If it matches you have a valid result. You can of course improve the security a little by using SHA-256 or SHA-512.
That's is just one way of doing it, but might not be the best. Better ways would be to use an authenticated mode of operation for AES like GCM or CCM, or use encrypt-then-MAC with a good MAC function like HMAC-SHA512.
With using the approaches above you're free to use any kind of data to encrypt, because you're not limited to determining if it is text or not anymore.
I'm trying to encrypt a string the same way on a server in PHP as on an Objective-C on iOS. I've used PHP's crypt() function with the blowfish algorithm, but it takes two parameters: the string to encode and a salt. The Objective-C implementation I found: https://dl.dropboxusercontent.com/u/28430840/Blowfish-iOS-Source.zip
which was at http://www.codeding.com/articles/blowfish-encryption-algorithm-for-iphone takes three different parameters: either EBC/CBC encoding, an initvector and a key -- how does this translate to the PHP salt?
I found the initial c library but I have no idea how to include it in my project -- when I compile it fails and complains about the x86.S file.
Thanks!!!
I suppose you are looking at the wrong function. It's not crypt what you search, but mcrypt_encrypt.
This function takes an init vector, a key and an encoding parameter.
I have the luxury of starting from scratch, so I'm wondering what would be a good hash to use between PHP and Python.
I just need to be able to generate the same hash from the same text in each language.
From what I read, PHP's md5() isn't going to work nicely.
md5() always plays nicely - it always does the same thing because it is a standard hashing format.
The only tripping hazard is that some languages default return format for an MD5 hash is a 32 byte ascii string containing hexadecimal characters, and some use a 16 byte string containing a literal binary representation of the hash.
PHP's md5() by default returns a 32-byte string, but if you pass true to the second argument, it will return the 16 byte form instead. So as long as you know which version your other language uses (in you case Python), you just need to make sure that you get the correct format from PHP.
You may be better using the 32-byte form anyway, depending on how your applications communicate. If you use a communication protocol based on plain-text (such as HTTP) it is usually safer to use plain-text versions of anything - binary, in this case, is smaller, but liable to get corrupted in transmission by badly written servers/clients.
The binary vs. ascii problem applys to just about any hashing algorithm you can think of.
What is it you want from the hash? (portability, security, performance....)
From what I read, PHP's md5() isn't going to work nicely.
What did you read? Why won't it work?
I just need to be able to generate the same hash from the same text in each language
Since PHP only provides crc32 (very insecure), md5 and sha1 out of the box, it's not exactly a huge amount of testing you need to do. Of course if portability is not an issue then there's the mcrypt and openssl apis available. And more recently the hash PECL gives you a huge choice.
I suggest to use sha1 as it is implemented out of the box in both but has no collision valnurabilities like md5. See: http://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities
I'd like to have a super simple / fast encrypt/decrypt function for non-critical pieces of data. I'd prefer the encryped string to be url-friendly (bonus points for pure alphanumerics), and no longer than it has to be. Ideally it should have some sort of key or other mechanism to randomize the cipher as well.
Because of server constraints the solution should not use mcrypt. Ideally it should also avoid base64 because of easier decrypting.
Example strings:
sample#email_address.com
shortstring
two words
or three words
555-123-4567
Capitals Possible?
You will probably have to code it yourself, but a Vigenère cypher on the characters A-Z, a-z, 0-9 should meet your needs.
With careful key generation and a long key (ideally longer than the encrypted text) Vigenère can be secure, but you have to use it very carefully to ensure that.
There's a wide variety of easy-to-implement ciphers around, such as XTEA. Don't invent your own, or use a trivially broken one like the vigenere cipher. Better yet, don't do this at all - inventing your own cryptosystems is fraught with danger, and if you don't want your users to view the data, you probably shouldn't be sending it to them in the first place.
Im currently using base64_encode for some $_GET params that i don't want regular user to mess with.
I was wondering that base64 is not looking too strong or is it ?
I also don't want to make some sort of mega encoding it's not so much of important information, but i would not like that user with average knowledge would mess with params in get.
Should i keep using base64 ? Currently it produces MQ== if value is 1 so it's quite easy to take it out from URL and decode and then insert your own.
Base-64 encoding doesn’t protect the data in any way. It’s a simply base conversion like using hexadecimal instead of decimal for integers.
If you just want to verify data integrity, you can use a salted hash (with a secret salt) that you store along with the data. See for example the hashed message authentication code (HMAC).
base64_encode() is not a security measure! It was designed to make sending of binary blobs possible through mediums that typically transfer ASCII only.
Use a session, or properly encrypt your variables.
I would recommend just using a session, and storing it out of the default /tmp for good measure with...
ini_set('session.save_path', '/sessions');
If you want some real encryption/decryption take a look at the Mcrypt features of PHP. http://www.php.net/manual/en/mcrypt.examples.php
But then you may want to use POST instead of GET because of the URL specifications which are limited in character usage and URL length.
Depends on what you want do do with it.
If you just want to obfuscate it (especially when you're generating those URLs in Javascript or so), you could apply ROT13 to the URL and swap a few additional characters to make decoding it a little bit more difficult.
However, if the security of your application depends on it, you could apply a static-key symmetric encrytion on the data server-side and decode it when you receive a request or so. I think that there are frameworks or so for that.