I am getting key events that contain asci key codes and I was wondering if there was any easy way to convert these to the actual key or character in common lisp. I am using the ccl implementation which does not include int-char (which may or may not have worked for this task).
You can use the code-char function. It will return the character encoded by given integer. Bear in mind that CCL uses Unicode, not pure 7-bit ASCII.
Related
I'm doing an R&D project focused on encrypting information into cipher-text and then printing it as a Code-128 barcode.
It is my understanding that since code-128 barcodes can only retain the ASCII table up to 128 characters. Therefore, I need to know if the cipher-text output of modern algorithms such as AES or RSA can be restricted to only the ASCII-128 table.
I am not doing any programming at this point, I am mainly trying to find precedence that this is can be done or has been done. If anyone knows the answer to this question, and better yet could provide a reference to an example, I would be very grateful.
bonus question... if restricting the ciphertext to ascii-128 is possible, how much could it affect encryption strength?
Encode resulting cipher-text, which is binary, with Base64, which is ASCII. Then you will be able to print base64-encoded cipher-text as
barcode.
Since Base64 encoding decoding doesn't change content, but rather changes its presentation, it doesn't affect underlying cryptography strength.
If resulting data won't fit into 103 (255) characters of Code 128, consider using QR Code instead.
I am fairly new to cryptography, but I have come across this :
ea706916-4d0a-460d-9778-4d1a7195b229
which looks like a familiar format. It's original value is tjotol.
Would anyone know what format the above code is in? I know that if it has hashes it can be a giveaway. Base64? HTML? Something else?
It does not look like Base64, it may be MD5 with dashes in-between. However, remember that a hash is a one-way function (ie. it's not reversible), while a cryptographic function is two-way (you can encrypt and decrypt it). Hence, it's not correct to speak about "hash decrypting". I don't know what you mean by "format language", would you care to elaborate on that?
A quick google search took me to this article that seems to be well written an covering many issues regarding your concern related to hashes being a "giveaway".
Note: Base64 is hardly an encryption algorithm, it is indeed just an encoding/representation format.
This have the format of a Globally unique identifier (GUID). Take a look here: Globally unique identifier
I am looking for a Stream Cipher encryption method, that will result in the encrypted string being prefferably as short as possible, and containing alphanumeric characters only.
Is there such a thing built in .NET? I have researched but could not find something like this.
Thank you,
I found the answer here Really simple short string compression, meaning its not possible, as encryption means also making the value longer. The best that can be done is keeping the same size of the input, but if the result must be alphanumeric then a longer string is a must
You can make it shorter - just zip the resulting encrypted string using java or some other library and output as hex. Pretty straight forward.
A lot of the examples online show the hash as a hex representation, and they are typically custom implementations. Is there anything wrong with, or less secure about, using the Apache Commons Base64 encoding instead? When reading about encoding, it is usually within the realm of how to represent binary as text in XML, but does not necessarily discuss security concerns... just how the compression works.
On a related issue, why encode it all, since databases have binary types that could probably hold the encryption as binary? So if I'm storing a password, why not just store it in its native type?
An encoding affects only the representation of the data, not its security. So, if you send an unencrypted password and use some form of encoding, you've not made it any more secure; likewise, if you take some highly encrypted text and then represent it in some encoding scheme, that won't make it any less secure, either. Typically, the reason to use this form of encoding is to send binary data using a protocol (such as SMTP), where the protocol is only capable of supporting 7-bit ASCII text. Another use is in URLs, where the set of characters that a URL can support is limited, but you might want to put arbitrarily complicated binary data in that URL (such as a validation signature of some sort).
Not at all. It's just an encoding that represents the same bits in ASCII. It is mostly useful when you have to store or transmit binary data over communications paths designed to handle only text. Modern examples ore email and web interfaces. You also can't send the binary form to a terminal to view it, since it would result in garbage or strange terminal behavior.
If you can safely store the bits in a binary blob in a database there is no reason to encode in base64. But if you don't it would be harder to view it. You would have to convert it back to a text form first.
Well we typically don't do too well reading binary, and hex is a better substitute for that. I wish you had linked to the articles you were referencing, so others could have a direct line on what it is you're forming an opinion from.
I don't understand why they would use Base64 over hex, but I'm assuming it's because hex is 16 digits and Base64 is a few more, thus generating a more compact version of the actual hash ;) ~ We humans tend to do better absorbing a small amount of data at a time.
No, because Base64 is a 1:1 encoding (that is, for every input there is exactly one base64 encoded output, and vice-versa), base64 encoding a SHA1 hash is just as “secure” as a hex-encoded (or binary-encoded, for that matter) hash.
The encoding would only make a hash insecure if the encoding made it possible for multiple hashes to encode to the same string, or multiple strings to decode to the same hash.
Just found this website: hashpass.com and here is the JS implementation which they use to encrypt the key-value pair: http://hashapass.com/sha1.js
So, can there be a "simple" and obvious alternative to this?
Thanks
I'm not sure how secure this is. For one thing, the output is a short Base64 string. Due to its length and restricted character set, it should be easier to brute-force than a regular password that avoids the common and dictionary values while combining alpha, numeric and other.
You want it to be simpler in <what?> way? You want it to be more obvious in <what?> way?
Do you care about the cryptographic strength?
If you don't care about that, you can simply take a sum modulo 2<<32 (or something) and encode the result as 8 hex digits.
I sure wouldn't trust my logon to that kind of security , but is
simple
obvious