I need to encrypt a string (from a text area) that will also be decrypted later on when it is displayed.
I'm not to concerned about it being majorly secure, but just don’t want to store the data in plain text format.
Does anyone have any suggestions on how to do this easily in Rails?
There is a RubyGem named Crypt that provides a pure Ruby implementation of a number of encryption algorithms.
gem install encryptor
It wraps the standard Ruby OpenSSL library and allows you to use any of its algorithms.
http://github.com/shuber/encryptor
Is there a ROT13 implementation in Ruby/Rails (there must be...) that's totally insecure except to human readers (and idiot savants) so seems to fit your use case.
EDIT - This is a good start for swapping out characters:
$_.tr! "A-Za-z", "N-ZA-Mn-za-m";
It asks for user input then swaps the characters.
EDIT If you're not familiar, ROT13 assigns each letter its natural number. A=1, B=2, etc. Then it adds 13 to each number, effectively spinning it half way around the alphabet. The halfway bit is great, because unlike, say, ROT12, you can just run ROT13 again to decode. One function for both. OR you could run ROT12 13 times I guess (12 * 13 = 156. 156/26 = 6.) ROT 13 is better for this though.
If you're not concerned about security you can just base64-encode your string:
encoded = Base64::encode(string)
decoded = Base64::decode(encoded)
By the way it's also suitable for encoding binary data.
This isn't really encrypting as any developer may even guess that its Base64 encoded data.
Related
I've used this popular library Hashids.
As this poster mentioned,Hashes produced by these algorithms are designed to be 'one-way'. Then, why is it possible for a hash value to be decoded?
I've read the documentation (and searched the issues), but don't see why hashes created by this library can be decoded.
I was about to ask this question in the git repo, but this is a question rather than an issue.
Any insight will be appreciated.
You find the reason in the documentation on the project site:
How does it work?
Hashids works similarly to the way integers are converted to hex, but with a few exceptions:
The alphabet is not base16, but base base62 by default.
The alphabet is also shuffled based on salt.
So, in short, this is not a hash at all, but merely an alternate encoding, more similar to a simple substitution cipher than to a hash (which would work as compression function). Which is, of course, pretty trivially reversible.
Today I decrypted some Lua 5.3 Bytecode, but I'm wondering why there are random letters coming up.
AH���U��H�D#�#�A�H��E#F������#�\��H�A ����U�G�E# F����I���E# F���I���E# F#���I����*p#�� 640#0stringformat%X�o#��#0#��# �####�#8�#��#��#��#��#<�#��#��##�#p�#n�#p�#��#n�#��#>�#��#`�##�#getRainbow0x00HacksHacksBackgroundColor CEPanel2Hacks 84itle��A�A�#A��disableMenuHacksdragNow���#ƀ��� ���PictureHacksHacksClose_On��E#F��F� #��PictureHacksHacksClose_Off���#ƀ��� ���Pictu 114eHacks
HacksLock_On��E#F��F� #��PictureHacksHacksLock_Off���#ƀ��� ���PictureHacksMenu_On��E#F��F� #��PictureHacks Menu_Off��EF#�F��#��#� #A 130��EF#���##��#��AI���Hacks CEPanel1Heighti#Enabled$#��EF#�F������EF�I�#�EF#�F������EF#�I�#��HacksPage2CheckedPage3Page1��EF#�F������EF�I�#�EF#�F������EF#�I 192#��HacksPage2CheckedPage1Page3��EF#�I�#�EF�I#A�EF��I#A�EF��I#B�EF��IÅEF#�I�Å�HacksHacksPage1visibleHacksPage2HacksPage3
HacksPageCaptionPage 1 of 3HacksPageDownColor
I got the bytecode from my friend. I decrypted it fast but I'd like to know if there's any way to fix those random letters or decrypt them. Any ideas? Thanks.
The � symbol is used when Unicode runs into "an unknown, unrecognizable or unrepresentable character." So either your decryption isn't working properly and is getting some corrupted characters, your friend's encryption isn't working properly and when he encrypted it, the data was corrupted, or somewhere in-between the bytecode was corrupted or altered in some way that is affecting the decryption.
I haven't done much messing around in Lua with bytecode, but I would suggest having a look at the Lua Unicode library page, or look into this module which provides support for UTF-8 for Lua and LuaJIT. Finally, this Stack Overflow question has a good explanation of how Lua's support for Unicode works.
Go back to your friend and double-triple check that the bytecode you decrypted is exactly identical to the bytecode after he encrypted it, and make sure that both your method of decryption and his method of encryption are working correctly.
For a work project I am using headless Squeak on a (displayless, remote) Linuxserver and also using Squeak on a Windows developer-machine.
Code on the developer machine is managed using Monticello. I have to copy the mcz to the server using SFTP unfortunately (e.g. having a push-repository on the server is not possible for security reasons). The code is then merged by eg:
MczInstaller installFileNamed: 'name-b.18.mcz'.
Which generally works.
Unfortunately our code-base contains strings that contain Umlauts and other non-ascii characters. During the Monticello-reimport some of them get replaced with other characters and some get replaced with nothing.
I also tried e.g.
MczInstaller installStream: (FileStream readOnlyFileNamed: '...') binary
(note .mcz's are actually .zip's, so binary should be appropriate, i guess it is the default anyway)
Finding out how to make Monticello's transfer preserve the Squeak internal-encoding of non-ascii's is the main Goal of my question. Changing all the source code to only use ascii-strings is (at least in this codebase) much less desirable because manual labor is involved. If you are interested in why it is not a simple grep-replace in this case read this side note:
(Side note: (A simplified/special case) The codebase uses Seaside's #text: method to render strings that contain chars that have to be html-escaped. This works fine with our non-ascii's e.g. it converts ä into ä, if we were to grep-replace the literal ä's by ä explicitly, then we would have to use the #html: method instead (else double-escape), however that would then require that we replace all other characters that have to be html-escaped as well (e.g. &), but then again the source-code itself contains such characters. And there are other cases, like some #text:'s that take third-party strings, they may not be replaced by #html's...)
Squeak does use unicode (ISO 10646) internally for encoding characters in a String.
It might use extension like CP1252 for characters in range 16r80 to: 16r9F, but I'm not really sure anymore.
The characters codes are written as is on the stream source.st, and these codes are made of a single byte for a ByteString when all characters are <= 16rFF. In this case, the file should look like encoded in ISO-8859-L1 or CP1252.
If ever you have character codes > 16rFF, then a WideString is used in Squeak. Once again the codes are written as is on the stream source.st, but this time these are 32 bits codes (written in big-endian order). Technically, the encoding is thus UTF-32BE.
Now what does MczInstaller does? It uses the snapshot/source.st file, and uses setConverterForCode for reading this file, which is either UTF-8 or MacRoman... So non ASCII characters might get changed, and this is even worse in case of WideString which will be re-interpreted as ByteString.
MC itself doesn't use the snapshot/source.st member in the archive.
It rather uses the snapshot.bin (see code in MCMczReader, MCMczWriter).
This is a binary file whose format is governed by DataStream.
The snippet that you should use is rather:
MCMczReader loadVersionFile: 'YourPackage-b.18.mcz'
Monticello isn't really aware of character encoding. I don't know the present situation in squeak but the last time I've looked into it there was an assumed character encoding of latin1. But that would mean it should work flawlessly in your situation.
It should work somehow anyway if you are writing and reading from the same kind of image. If the proper character encoding fails usually the internal byte representation is written from memory to disk. While this prevents any cross dialect exchange of packages it should work if using the same image kind.
Anyway there are things that should or could work but they often go wrong. So most projects try to avoid using non 7bit characters in their code.
You don't need to convert non 7bit characters to HTML entities. You can use
Character value: 228
for producing an ä in your code without using non 7bit characters. On every character you like to add a conversion you can do
$ä asciiValue => 228
I know this is not the kind of answer some would want to get. But monticello is one of these things that still need to be adjusted for proper character encoding.
I'm using the DCPcrypt library in Delphi 2007 for encrypting text for an in-house app.
I'm currently using the following code (not my actual key):
Cipher := TDCP_rijndael.Create(nil);
try
Cipher.InitStr('5t#ck0v3rf10w', TDCP_md5);
Result := Cipher.EncryptString('Test string');
finally
Cipher.Burn;
Cipher.Free;
end;
The comment for InitStr is:
Do key setup based on a hash of the key string
Will exchanging the MD5 algorithm for, say, SHA2-256 or SHA2-512 make any theoretical or actual difference to the strength of the encryption?
The direct answer to your question is 'No' - it won't make any appreciable difference to cryptographic strength. Yes, MD5 is broken, but really it's weakness does not make any difference in this particular application. AES has key sizes of 128, 192 and 256 bits. All you are doing here is creating a string pseudonym for a key (being either 16 bytes, 24 bytes or 32 bytes). When cryptographic experts say that a hash function is broken, what they mean by this is that given a known hash output, it is feasible to compute a message different from the original message, which also hashes to the same output. In other words, in order for the cryptographic strength or weakness of the hash function to have any meaning, the binary key must already be known to the malicious party, which means that it is only relevant when your security is already completely defeated.
The strength of the hashing algorithm is COMPLETELY irrelevant to the strength of the asymmetric cipher.
However...
However, of a much more serious concern is the lack of salting in your code. Unless you plan to manually salt your message (unlikely), your communications are very vulnerable to replay attack. This will be infinity worse if you use ECB mode, but without salting, it is a major security issue for any mode. 'Salting' means injecting a sufficiently large non-predictable non-repeating value in either the IV or at the head of the message before encryption.
This highlights a huge problem with DCPCrypt. Most users of DCPcrypt will not know enough about cryptography to appreciate the importance of proper salting, and will use the crypto component in exactly the way you have. When you use DCPcrypt in this way (which is very natural), DCPcrypt does NOT salt. In fact, it sets the IV to zero. And it gets worse... If you have chosen a key-streaming type of chaining mode (which is very popular), and your IV is habitually zero, your security will be completely and utterly broken if a single plaintext message is known or guessed, (OR even just a fragment of the message is guessed). DCPcrypt does offer an alternative way to initialize a binary key (not from string), together with allowing the user to set the IV (you must generate a random IV yourself). The next problem is that the whole IV management gets a bit complicated.
Disclosure
I am the author of TurboPower LockBox 3. Dave Barton's DCPcrypt, an admirable and comprehensive engineering work, was one of my inspirations for writing LockBox 3.
You should specify the type of attack on your encryption; suppose known-plaintext attack is used, and intruder uses precomputed hash values to find key string - then there should be no difference between the hash algorithms used, any hash algorithm will require nearly the same time to find key string.
I'm trying to find a bcrypt implementation I can use in Delphi. About the only useful thing that Googling brings me is this download page, containing translated headers for a winapi unit called bcrypt.h. But when I look at the functionality it provides, bcrypt.h doesn't appear to actually contain any way to use the Blowfish algorithm to hash passwords!
I've found a few bcrypt implementations in C that I could build a DLL from and link to, except they seem to all require *nix or be GCC-specific, so that won't work either!
This is sorta driving me up the wall. I'd think that it would be easy to find an implementation, but that doesn't seem to be the case at all. Does anyone know where I could get one?
Okay, so i wrote it.
Usage:
hash: string;
hash := TBCrypt.HashPassword('mypassword01');
returns something like:
$2a$10$Ro0CUfOqk6cXEKf3dyaM7OhSCvnwM9s4wIX9JeLapehKK5YdLxKcm
The useful thing about this (OpenBSD) style password hash is:
that it identifies the algorithm (2a = bcrypt)
the salt is automatically created for you, and shipped with the hash (Ro0CUfOqk6cXEKf3dyaM7O)
the cost factor parameter is also carried with the hash (10).
To check a password is correct:
isValidPassword: Boolean;
isValidPassword := TBCrypt.CheckPassword('mypassword1', hash);
BCrypt uses a cost factor, which determines how many iterations the key setup will go though. The higher the cost, the more expensive it is to compute the hash. The constant BCRYPT_COST contains the default cost:
const
BCRYPT_COST = 10; //cost determintes the number of rounds. 10 = 2^10 rounds (1024)
In this case a cost of 10 means the key will be expanded and salted 210=1,024 rounds. This is the commonly used cost factor at this point in time (early 21st century).
It is also interesting to note that, for no known reason, OpenBSD hashed passwords are converted to a Base-64 variant that is different from the Base64 used by everyone else on the planet. So TBCrypt contains a custom base-64 encoder and decoder.
It's also useful to note that the hash algorithm version 2a is used to mean:
bcrypt
include the password's null terminator in the hashed data
unicode strings are UTF-8 encoded
So that is why the HashPassword and CheckPassword functions take a WideString (aka UnicodeString), and internally convert them to UTF-8. If you're running this on a version of Delphi where UnicodeString is a reserved word, then simply define out:
type
UnicodeString = WideString;
i, as David Heffernan knows, don't own Delphi XE 2. i added the UnicodeString alias, but didn't include compilers.inc and define away UnicodeString (since i don't know the define name, nor could i test it). What do you want from free code?
The code comprises of two units:
Bcrypt.pas (which i wrote, with embedded DUnit tests)
Blowfish.pas (which Dave Barton wrote, which i adapted, extended, fixed some bugs and added DUnit tests to).
Where on the intertubes can i put some code where it can live in perpetuity?
Update 1/1/2015: It was placed onto GitHub some time ago: BCrypt for Delphi.
Bonus 4/16/2015: There is now Scrypt for Delphi