I'd like to create a bash script to encrypt my personal (text) files, and decrypt them when I need them.
The encryption method I want is, to convert all ASCII characters to hex, then add a value, and convert back to ASCII.
The value to add should be the hex value of a certain character in the file - based on it's position, so it would vary depending on what character happens to be there.
I know next to nothing about bash scripting and about Linux at all for that matter, can anyone please help me?
Unless you trying to learn the history of cryptography forget about this. Anyone with limited knowledge of cryptography will break your code in minutes. A determined hacker will break this in seconds (using frequency analysis of single letters, doublets and triplets).
For encryption (approach you described can hardly be called encryption. It is rather cipher), use stable, proven algorithms (AES, 3DES, TwoFish, Serpent) and tools, such as GPG, TrueCrypt.
Related
First Question: Say I have a random Base64 encoded string. Is it possible to read each character on the string and convert each character to a frequency/sound and then same the string as a sound?
Second Question: Is it possible to do the opposite? How would I take a sound that was created above and convert back to a base64 string?
If someone clicked no the audio encrypted file it would just be noise.
Yes, it's possible and actually being used, for example here: http://arstechnica.com/tech-policy/2015/11/beware-of-ads-that-use-inaudible-sound-to-link-your-phone-tv-tablet-and-pc/
A Perl script for this is beyond a single answer, but there are many Sound-related modules on CPAN: http://search.cpan.org/search?query=sound&mode=all You'll probably need some time for research, but it should be more or less easy to build.
How to decrypt a string with unknown encryption algorithm?
There is a string:
5aaC5p6c5L2g5a+55oiR5Lus5Zyo5YGa55qE5LqL5oOF5pyJ5YW06Laj77yM5bm25LiU5a+5cmFpbHMv5YmN56uv5byA5Y+R5pyJ6Ieq5L+h77yM5qyi6L+O5Y+R6YCB6YKu5Lu25YiwZ2hvc3RtNTVAZ2l0Y2FmZS5jb23pooTnuqbkuqTmtYHml7bpl7TvvIznoa7lrprkuYvlkI7lj6/ku6Xnm7TmjqXmnaXliLDmiJHku6znmoTlt6XkvZzlrqTlj4Lop4LkuqTmtYHvvIzosKLosKIK
I don't know the encryption algorithm. How to decrypt it?
To analyze and solve this problem, what should I learn?
It's not an encryption algorithm, it's base64. You can tell because of the +s.
http://www.opinionatedgeek.com/dotnet/tools/base64decode/
Try running it through this page, it'll turn into this:
如果你对我们在做的事情有兴趣，并且对rails/前端开发有自信，欢迎发送邮件到ghostm55#gitcafe.com预约交流时间，确定之后可以直接来到我们的工作室参观交流，谢谢
NOTE: If it was actually encrypted and you actually had no clue what it was encrypted with, you would be screwed, because any good encryption algorithm turns the output into meaningless gibberish, unusable without the key. Base64 has no key, you can just reverse it the same way every time.
This string appears to be a Base64 encoded string.
The decoded value is: 如果你对我们在做的事情有兴趣，并且对rails/前端开发有自信，欢迎发送邮件到ghostm55#gitcafe.com预约交流时间，确定之后可以直接来到我们的工作室参观交流，谢谢
Well, the string is likely Base64 encoded. If you decode it, you should get an effectively random piece of binary data if its encrypted (EDIT: As others have shown, it isn't encrypted, but the following would still apply if it were)
By checking the length, you can determine the block-size of the cipher. If its not an even block size, it likely could be a stream cipher (or a block cipher operated in stream mode).
However, any more information will need to be gleamed from other sources - as the point of good encryption is to make the data truly opaque.
Its Base 64 encryption.The above code is translated as:
如果你对我们在做的事情有兴趣，并且对rails/前端开发有自信，欢迎发送邮件到ghostm55#gitcafe.com预约交流时间，确定之后可以直接来到我们的工作室参观交流，谢谢
"If you are doing things we are interested in, and on the rails / front-end developers are confident, please send e-mail to communicate ghostm55#gitcafe.com appointment time, after determining the direct exchange of visits to our studio, thank you"
I'm currently building a hash key string (collapsed from a map) where the values that are delimited by the special ASCII unit delimiter 31 (1F).
This nicely solves the problem of trying to guess what ASCII characters won't be used in the string values and I don't need to worry about escaping or quoting values etc.
However reading about the history of this is it appears to be a relic from the 1960s and I haven't seen many examples where strings are built and tokenised using this special character so it all seems too easy.
Are there any issues to using this delimiter in a modern application?
I'm currently doing this in a non-Unicode C++ application, however I'm interested to know how this applies generally in other languages such as Java, C# and with Unicode.
The lower 128 char map of ASCII is fully set in stone into the Unicode standard, this including characters 0->31. The only reason you don't see special ASCII chars in use in strings very often is simply because of human interfacing limitations: they do not visualize well (if at all) when displayed to screen or written to file, and you can't easily type them in from a keyboard either. They're also not allowed in un-escaped form within various popular 'human readable' file formats, such as XML.
For logical processing tasks within a program that do not need end-user interaction, however, they are perfectly suitable for whatever use you can find for them. Your particular use sounds novel and efficient and I think you should definitely run with it.
Your application is free to accept whatever binary format it pleases. However, if you need to embed arbitrary binary data in your input, you need to escape whatever delimiters or other special codes your format uses. This is true regardless of which ones you choose.
I'd also not ignore Unicode. It's 2012, by now it's rather silly to work with an outdated model for dealing with text. If your input data is textual, handle it as such.
The one issue that comes to mind is why invent another format instead of using XML or JSON; or if you need a compact encoding, a "binary" variant of those two (Fast Infoset, msgpack, who knows what else), or ASN.1? There's probably a whole bunch of other issues that you'll encounter when rolling your own that the design and tooling for those formats already solved.
I work with barcodes in a warehouse setting. We use ASCII code 31 as a field-separator so that a single scan can populate multiple data fields with a single scan. So, consider the ramifications if you think your hash key could end up on a barcode.
In ruby how to check a string is an actural string or a blob data such as image, from the data type of view they are ruby string, but really their contents are very different since one is literal string, the other is blob data such as image.
Could anyone provide some clue for me? Thank you in advance.
Bytes are bytes. There is no way to declare that something isn't file data. It'd be fairly easy to construct a valid file in many formats consisting only of printable ASCII. Especially when dealing with Unicode, you're in very murky territory. If possible, I'd suggest modifying the method so that it takes two parameters... use one for passing text and the other for binary data.
One thing you might do is look at the length of the string. Most image formats are at least 500-600 bytes even for a tiny image, and while this is by no means an accurate test, if you get passed, say, a 20k string, it's probably an image. If it were text, it would be quite a bit (Like a quarter of a typical novel, or thereabouts)
Files like images or sound files have defined blocks that can be "sniffed". Wotsit.org has a lot of info about the key bytes and ways to determine what the files are. By looking at those byte offsets in your data you could figure it out.
Another way way is to use some "magic", which is code to sniff key-bytes or byte-types in a file to try to figure out what its type is. *nix systems have it built in via the file command. Do a man file or man magic for more info or check Wikipedia's article on Magic numbers in files.
Ruby Filemagic uses the same technique but is based on GNU's libmagic.
What would constitute a string? Are you expecting simple ASCII? UTF-8? Or text encoded some other way?
If you know you're going to get ASCII text or a blob then you can just spin through the first n bytes and see if anything has the eight bit set, that would tell you that you have binary. OTOH, not finding anything wouldn't guarantee that you had text.
If you're going to get UTF-8 Unicode then you'd do the same thing but look for invalid UTF-8 sequences. Of course, the same caveats apply.
You could scan the first n bytes for anything between 0x00 and 0x20. If you find any bytes that low then you probably have a binary blob of some sort. But maybe not.
As Tyler Eaves said: bytes are bytes. You're starting with a bunch of bytes and trying to find an interpretation of them that makes sense.
Your best bet is to make the caller supply the expected interpretation or take Greg's advice and use a magic number library.
I am trying to create a ticket for Remote Assistance. Part of that requires creating a PassStub parameter. As of the documentation:
http://msdn.microsoft.com/en-us/library/cc240115(PROT.10).aspx
PassStub: The encrypted novice computer's password string. When the Remote
Assistance Connection String is sent as a file over e-mail, to provide additional security, a
password is used.<16>
In part 16 they detail how to create as PassStub.
In Windows XP and Windows Server 2003, when a password is used, it is encrypted using
PROV_RSA_FULL predefined Cryptographic provider with MD5 hashing and CALG_RC4, the RC4
stream encryption algorithm.
As PassStub looks like this in the file:
PassStub="LK#6Lh*gCmNDpj"
If you want to generate one yourself run msra.exe in Vista or run the Remote Assistance tool in WinXP.
The documentation says this stub is the result of the function CryptEncrypt with the key derived from the password and encrypted with the session id (Those are also in the ticket file).
The problem is that CryptEncrypt produces a binary output way larger than the 15 byte PassStub. Also the PassStub isn't encoding in any way I've seen before.
Some interesting things about the PassStub encoding. After doing statistical analysis the 3rd char is always a one of: !#$&()+-=#^. Only symbols seen everywhere are: *_ . Otherwise the valid characters are 0-9 a-z A-Z. There are a total of 75 valid characters and they are always 15 bytes.
Running msra.exe with the same password always generates a different PassStub, indicating that it is not a direct hash but includes the rasessionid as they say.
Another idea I've had is that it is not the direct result of CryptEncrypt, but a result of the rasessionid in the MD5 hash. In MS-RA (http://msdn.microsoft.com/en-us/library/cc240013(PROT.10).aspx). The "PassStub Novice" is simply hex encoded, and looks to be the right length. The problem is I have no idea how to go from any hash to way the PassStub looks like.
I am curious, have you already:
considered using ISAFEncrypt::EncryptString(bstrEncryptionkey, bstrInputString) as a higher-level alternative to doing all the dirty work directly with CryptEncrypt? (the tlb is in hlpsvc.exe)
looked inside c:\WINDOWS\pchealth\helpctr\Vendors\CN=Microsoft Corporation,L=Redmond,S=Washington,C=US\Remote Assistance\Escalation\Email\rcscreen9.htm (WinXP) to see what is going on when you pick the Save invitation as a file (Advanced) option and provide a password? (feel free to add alert() calls inside OnSave())