I'm sending ciphers over the network and verifying that they can be decrypted before sending them out and they consistently come out of the test as functioning properly, yet when they get sent over the network, they no longer decrypt properly. This doesn't happen consistently. They get sent through and decrypt as they should more commonly than otherwise, however they are failing to decrypt often enough to create serious problems. I am guessing that some of the characters that are used in the cipher are not intended to travel over a network, so they are replaced at some point and thus the cipher returns from its journey in a broken state. It's just a guess, though. Anyone have any ideas?
details:
require 'openssl'
require 'digest/sha1'
cipher = OpenSSL::Cipher::Cipher.new("aes-256-cbc")
cipher.encrypt
key = Digest::SHA1.hexdigest("password")
iv = cipher.random_iv
The error messages I'm getting are mostly 'bad decrypt' but also 'iv length too short' and 'wrong final block length'. It seems to be related to time somehow because I seem to get either a streak of errors or a streak of clean decrypts more often than things being mixed so that kind of points toward a cipher character issue in my mind.
The encrypted text and the IV are strings are binary and thus contain characters that are unsafe to send over a network. You can unpack your binary string into hex and the send that over.
encrypted.unpack("H*).first
And on the other end:
encrypted_data = [hex_data].pack("H*")
Related
Does telnet sub negotiation command without IAC SE is valid command?
No, the IAC, SE sequence indicates the end of the response (and the supplied value).
See Documentation
Like #Robert Bradley says, a sub-option negotiation which does not end with <IAC><SE> is NOT valid.
However there is one unofficial exception, which, because it was broken like that, got replaced, but theoretically could be seen in the wild. That is the original version of the Mud Client Compression Protocol (MCCP) - using sub-option number 85 which uses zlib compression to reduce the amount of data bytes to be sent from a MUD (Multi-User Dungeon) Game Server to the players' Clients. That mistakenly has the Server using <IAC><SB><85><WILL><SE> at the exact point in the data where compression begins. This defect was so significant that the protocol was revised to version 2 - which is otherwise identical except that it uses the sub-option number 86 instead - so that the sequence to begin that (after both server and client have agreed) is the correctly formed: <IAC><SB><86><IAC><SE>.
MUD server and client applications are now to prefer MCCP2 over MCCP1 (and obviously not agree to do the latter if the former has already been negotiated). See also: https://smaugmuds.afkmods.com/mccp/protocol.html.
A SharpSnmpLib SNMP V1 GET snmpexception is thrown when querying a certain vendor equipment located in remote networks. Other software like iReasoning MIB Browser, SNMPB, or SnmpSharpNet work OK on the same OID and equipment.
The error varies even though the equipment is the same and the OID the same but located in a different network. It seems like a Data segment is added to the end of the UDP packet. One one piece of equipment the error message might be: "BER end of file", and on another identical piece of equipment, the error message is "unsupported data type:34", or "unsupported data type:115" and so on. Many different data types found on the same OID but from different pieces of equipment.
The error occurs in the project source file "MessageFactory.cs" in the ParseMessage routine. If I catch the error and continue the program works OK. I ignore the error for the trailing portion of data bytes that are not properly parsed.
The wireshark packets are also shown below:
And here is another error on another piece of exact same SNMP device and OID, just different IP address.
It seems like the trailing Data portion causes the API to throw an error because it does not recognize it as valid variable. Yet other software packages handle this without seeming error messages. I will have to modify the source code for Sharp SNMP to use the API unless finding a better solution. My modification involves catching the error and moving on. The first variable in the loop is already found and produces the proper value. The error occurs when continuing on from the first variable because the stream has not reached the end.
use the form that has (message, start, length, registry)
this works because it only reads from start to length and not the trailing problems
I can read files encrypted with ccat file or ccrypt -c file in Bash with ccrypt.
How can I append an encrypted file without doing the decryption process?
You can program this, but you can probably not perform this from the command line.
The description of the protocol can be found here. It uses full block CFB where the previous ciphertext block is encrypted again to create a stream that is XOR'ed with the plaintext.
A quick look at the Wikipedia page shows that you can just grab the last full ciphertext block, use that as IV, skip the bytes of the result used for any partial ciphertext block (if present) and then continue encrypting.
However, you'll have to program that yourself. Good luck!
We are using a custom board based on Beaglebone black (AM335x). To upgrade the board’s firmware, we shall be using an encrypted firmware image.
As you would have already guessed, we will be using symmetric encryption to encrypt a large firmware file (fimware.tar) and then encrypt the symmetric key with an asymmetric key. So we have two files which to give to the user for upgrading his board.
We don’t want to do that; we want to give only one file to each user. So we have to somehow combine the encrypted firmware image and the encrypted symmetric key.
I thought of two strategies. The firmware is encrypted using a bash script.
Tar the encrypted firmware and the encrypted symmetric key.
Problem: This is very slow.
Append the encrypted symmetric key to the encrypted tar file.
Problem: This doesn’t feel like a clean approach, does it?
Are there any better (and faster) ways to handle this?
There are a few ways to do this:
use a well known container format such as OpenPGP or CMS;
pick a less well known / standardized format that happens to confirm to your requirements;
define your own container format.
Option 1 should of course be preferred as this is likely the most secure option. It will also mean you can use standard libraries.
Option 2 requires you to perform research to see if that option fits your needs and is secure.
Option 3 would be a good option if code and format size optimization is a prime concern.
For option 3 you could e.g. use a version / format specifier (1 byte), then the wrapped key (prefixed with a length) and then the firmware (anything after the wrapped key).
I manage my accounts for websites with KeePass. This tool generates highly complex passwords, such as d,ªL¹(ç,z/¬gSÑ~}ÄwÚÆ¡íµ¯ó]ó6õ?Ô£fß,.
Such a complex password I use for example for Red Hat’s OpenShift website.
OpenShift servers/applications can be managed best by using their rhc command line tool.
Now, while running rhc setup I have to enter my password. So I copy it into the clipboard and paste it into the shell, where rhc sits and waits for my PW. However, the password won’t get accepted.
The process of pasting probably causes some changes. I already tried doing chcp 1252 and chcp 65001 before running rhc setup. Unfortunately this also didn’t help. The only way to get it running was changing my password to a trivial one on the OpenShift website, then doing the setup, and then changing the password back to a complex one.
Anyways, now I want to log in to my applications via rhc ssh, which is asking for the password of my ssh keys. And as everyone can guess, my ssh key is protected by a password in the style above. This is no problem because pasting such passwords into Putty or other GUI applications works great.
So I wonder: is there a way how I can do safe pasting into windows shells?
I commend you on your passwords!
There's two major possibilities:
Some characters need to be escaped
Shift to a longer password without the escape-requiring characters
Escape the characters!
Code page fun, i.e. some characters are being transformed
Figure out the mapping and duplicate your KeePass entry with one that will map to the correct values for that login type
Shift to a longer password without the escape-requiring characters
Assuming your password (unlikely) is a 35 character password using all 256 possible 8 bit values, that's a maximum exhaustive keyspace of 256^35, roughly 2E84 or 2^280. You can achieve a slightly higher maximum exhaustive keyspace with a password of 43 charactres containing Upper, Lower, Number, and normal US keyboard symbols (94^43), or 48 characters containing Upper, Lower, and Number (62^48).
The Upper, Lower, Number password of length 48 shouldn't cause any problems with escaped characters, and is far less likely to cause problems with code page transforms.
Note that both of those are likely to be superior against the edge case of an attacker who knows which characters were actually used :).
Note also that even a 35 character password containing only Upper, Lower, and Number has a maximum exhaustive keyspace of 62^35, or 5.4E62, or 2^208; 208 bits is likely to substantially exceed the amount of security provided by your transport layer and/or their storage mechanism.
*All passwords in this math are assumed to be 100% cryptographically random!