We Keep Coding

Java implementation of 3DES and DUKPT for decryption of credit card reader data through keyboard emulation?

We have an online key-in interface, and are support credit card swipe capability. In the industry today, the card reader should encrypt the information before encoding it to ASCII, and then it is up to server-side to decrypt. (so the local machine never sees the card info)
I am using MagTek card reader in keyboard emulation mode, and have it with the ANSI standard key injected for testing purposes. Once decode & decryption successful, we'll get our own key registered with MagTek and order some production-use readers.
I know this decryption has been implemented before in C# and other languages, but need something in Java, or perhaps some other CLI-accessible program that can be included with a Java webapp. I am about to proceed with porting some C# code to Java, but first need to set up a C# environment. (I've never done this before.)
Once I've ensured the C# version works well, then I know I can eliminate any errors during porting with my usual debugging techniques.
Before I go through all of this, if there is an easier way please let me know. I would think this has already been done in Java, but perhaps not...

Partial answer, CW for anyone to add to.
First, it's not clear (to me) if you want to run on PCs or similar where the swipe devices are, possibly downloaded (like applet or webstart), or to just get the encrypted swipe data (in a webform?) and send it to your server to decrypt. I suggest the latter makes PCI DSS compliance easier.
Java crypto certainly does 3DES, under the name DESede (case-insensitive, like all JCA Cipher names). One slightly unobvious point: the implementation in SunJCE only handles full 24-byte keys. DUKPT uses "2-key 3DES", so you need to copy "left" to bytes 0-7, "right" to 8-15, and "left" again to 16-23. If you use BouncyCastle (as my shop does) it can take a 16-byte key and do the copy internally, which is slightly more convenient. (A symmetric key in Java is a byte array in a thin wrapper class, usually javax.crypto.spec.SecretKeySpec.)
If you're not familiar with Java crypto in general, the pattern is that you obtain an "instance" of a particular algorithm or mode from a "provider" (you can specify one or let Java choose automatically; several are builtin and more can be added, like "bcprov" from www.BouncyCastle.org) using a generic API class Cipher, Signature, MessageDigest, etc, then initialize that instance with needed parameters (such as key or IV, and direction), then call methods to take input data and return output either in separate (possibly multiple) steps or in a simple combined doFinal (which is fine for your case). The JCA manual http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html#Cipher and javadoc for the applicable API class javax.crypto.Cipher (at http://docs.oracle.com/javase/8/docs/api/index.html and also automatically displayed in leading IDEs) has quite full details on this.
I haven't seen any open/free implementation of DUKPT but that doesn't prove there isn't one. It is straightforward, though a bit tedious, to just code the steps from X9.24, if no one offers better.

Is there a standard/well-developed way to serialize Java classes for use in C++ without using a markup format like XML or JSON?

I'm working on a project that will eventually involve Java objects with several billion total fields, and some back-of-the-envelope calculations show that standard serialization techniques will quickly become intractable for inputs of this length (think a 20 gig JSON file). Are there any alternative techniques known?

I would probably use Sun's XDR format. It's binary, so figure 1/3rd the size of text-based formats as a starting point for size. Although they're not (to my knowledge) included in the Java distribution, there are a few libraries to produce/read this format in Java and C++. Since it's used in Sun's ONC RPC, the protocol (and at least some library implementations) have been tested heavily over the years. It's also standardized in RFC 4506, so you can be about as independent of Oracle as you see fit.

take a look at protocol buffer
If you have collection of objects and you don't expect a single message (like a big xml) it may work.

You can define some ASN.1 grammar and code/decode your data using common encoding rules i.e. DER, PER, etc.
This flexible notation is used in most common protocols over TCP, such as LDAP. It might be the most efficient way to communicate different platforms, but you have to learn some asn.1 basics and define the grammar. Then implement the marshallers/unmarshallers in Java and also in C++.
Check ASN.1 in Wikipedia
Check also Bouncy Castle

You can write custom implementation of Serializable for your Java objects.

You might try ASN.1 (yes, I know someone else suggested this here already, but I have some additional information to add). Since your concern is regarding the size of the data, please note that telephone operators use ASN.1 to handle their CDRs (Call Data Records) in handling the billing of phone calls (whether via land lines, or mobile phones). They bundle hundreds or thousands of call records into a single message that gets to their billing centers.
My suggestion would be to use PER (Packed Encoding Rules) which was designed originally for the aviation industry due to their need for minimizing bandwidth in Air to Ground communications. PER was subsequently picked up by the mobile telephony industry where it is currently part of many 3G and 4G protocols.
PER's objective is to avoid sending information over the wire that both communicating parties already know. So for example, if a field has a fixed length, there is no need to send the length in the message. If a value has a range, for example, from 5000 to 5007, there are only 8 posible values, so only 3 bits would be used to represent that value. This is part of why PER achieves such compactness.
Finally, use of a good ASN.1 Tool makes it unnecessary for you to concern yourself about the details mentioned in the previous paragraph. All you need to do is create the ASN.1 specification describing the information you would like to exchange (which is easy to do - see ASN.1 Made Simple), choose your programming language (C, C++, Java, C# are some of the common ones, but others are also available in some ASN.1 Tools), then use the ASN.1 compiler to generate the serializer/deserializer engine for you. Note that since ASN.1 itself is independent of the programming language you use, you can easily serialize in C++ and deserialize in Java or vice versa.
You can find a list of ASN.1 Tools (some free, some commercial) at the following URL: http://www.itu.int/ITU-T/asn1/links/index.htm

Manual Encryption

I want to send secure data(strings) from a client to a server. This is what i think i want to do:
Turn the string into a byte array
"scramble" the bytes by putting them out of order in a specific way
Serialize array of bytes inside of a class
send the Encrypted and Serialized class to the server
then the server would:
Deserialize the class
get the bytes for the string
put the bytes in the right order
make a string out of the bytes
would this be a good way to Manually Encrypt data? Is this secure? Is it even worth the time trying to make a manual encrypter?

It sounds like you're trying to roll your own symmetric encryption scheme, using a fixed key (the "specific way" you're scrambling the bytes) known to both sides. There's no advantage to doing this over simply using a build-in encryption scheme with a known key, and substantial potential disadvantages. It takes just a small implementation mistake to create an opening that malign users can exploit.
Unless you do encryption for a living, you can't do better than what's out there, known, and proven in the field (AES is a good start). If security is important to you, don't try. If you want to experiment as a hobby, though, have fun.

Would this be a way to encrypt the data?
If you're just "scrambling" the data, no. It would be "trivially possible" to reconstruct the plaintext if it's just being scrambled. (This means the first time someone wants to read the data, they probably will, but if they're not trying too hard, they won't stumble across it by accident.)
On the other hand, if you're then running a "real" encryption algorithm over it, the scrambling adds a negligible degree of difficulty to the decryption, but you're relying upon a simple scrambling being sufficient to slow down someone who's just cracked the "real" encryption, which seems unlikely to be worthwhile.
You'd probably do far better to stick with a well-tested encryption mechanism designed by someone who does math with very large prime numbers for a living. Java's encryption framework lets you fairly easily implement a public/private key system, or a double-blind key exchange system; for example, you can just use HTTP-SSL for data exchange without much set-up on your part.

No, jumbling is not very goood. For a simple scheme you can build on check out the XOR operator.

How to protect decryption key from decompilation?

I'm a beginner java programmer. I'm working on an application that decrypts some data.
The decryption key is hardcoded into the software and thus can be seen by analyzing the bytecode.
I know that reverse engineering cannot be prevented entirely so what I'm trying to do is to make the process as hard as possible.
My idea is not to directly put the key into my code but have it go through some kind of transformation.
For example, I could write -
private static final byte[] HC256A = Hex
.decode("8589075b0df3f6d82fc0c5425179b6a6"
+ "3465f053f2891f808b24744e18480b72"
+ "ec2792cdbf4dcfeb7769bf8dfa14aee4"
+ "7b4c50e8eaf3a9c8f506016c81697e32");
This way someone looking at the bytecode can't read it straight away. But will have to follow the logic and apply transformations to it, which won't be that much easier at byte level.
So what do you guys think? Is this useful? What could be the be the best transformation other than hex decoding?
Are there any other methods available to protect hardcoded decryption keys?
Thanks for all your suggestions.

Right way to attack such obfuscation (especially in bytecode languages) is to attach debugger to the place to which the key is passed (if debugging is not possible, start analyzing code from that place). This way the attacker doesn't need to look for the key at all and he doesn't care how obfuscated the key is. So you need to re-think your design.
If you only want to protect from the amateur lurkers, then splitting the key and XORing it's parts (possibly with different keys), would be enough. One more trick - derive the key from text constants already present in the code (such as application name). This makes the key less obvious than splitting or XORing.

Don't code the key into the source code at all. Keep it separate, ship it separately, e.g. in a Java keystore, and only to customers/sites/clients you trust, and put some legalese in the licence that places the onus on them if they leak the keystore.

Faced with a similar problem (in c) I went with single use XOR pads. This is good because it looks like garbage... if you get really clever you can snoop for that (incorrect) key in use. I would avoid anything that injects human readable strings as those will invariably draw attention to that bit of code.

Parsing IBM 3270 data in java

I was wondering if anyone had experience retrieving data with the 3270 protocol. My understanding so far is:
Connection
I need to connect to an SNA server using telnet, issue a command and then some data will be returned. I'm not sure how this connection is made since I've read that a standard telnet connection won't work. I've also read that IBM have a library to help but not got as far as finding out any more about it.
Parsing
I had assumed that the data being returned would be a string of 1920 characters since the 3278 screen was 80x24 chars. I would simply need to parse these chars into the appropriate fields. The more I read about the 3270 protcol the less this seems to be the case - I read in the documentation provided with a trial of the Jagacy 3270 Java library that attributes were marked in the protocol with the char 'A' before the attribute and my understanding is that there are more chars denoting other factors such as whether fields are editable.
I'm reasonably sure my thinking has been too simplistic. Take an example like a screen containing a list of items - pressing a special key on one of the 24 visible rows drills down into more detailed information regarding that row.
Also it's been suggested to me that print commands can be issued. This has some positive implications - if the format of the string returned is not 1920 since it contains these characters such as 'A' denoting how users interact with the terminal, printing would eradicate these. Also it would stop having to page through lots of data. The flip side is I wouldn't know how to retrieve the data from the print command back to Java.
So..
I currently don't have access to the SNA server but have some screen shots of what the terminal will look like once I get a connection and was therefore going to start work on parsing. With so many assumptions and not a lot of idea on what the data will look like I feel really stumped. Does anyone have any knowledge of these systems that might help me back on track?

You've picked a ripper of a problem there. 3270 is a very complex protocol indeed. I wouldn't bother about trying to implement it, it's a fool's errand, and I'm speaking from painful personal experience. Try to find a TN3270 (Telnet 3270) client API.

This might not specifically answer your question, but...
If you are using Rational Developer for z/OS, your java code should be able to use the integrated HATS product to deal with the 3270 stream. It might not fit your project, but I thought I would mention it if all you are trying to do is some simple screen scraping, it makes things very easy.