DISCLAIMER: any implementation of the following should be reviewed and analyzed before being used in a non-test environment. I have tested an implementation that operates as expected for 32 and 64-bit inputs, but proper round counts have not been determined.
Most modern block ciphers already use building blocks that operate on 32-bit integers as they are designed to be implemented on general purpose hardware. These include Blowfish and AES. Blowfish uses a 32-bit operation in the F function, and AES uses 4 parallel 32-bit MDS matrix multiplications. These building blocks are well studied and provide good diffusion, they are combined with other operations to extend the effective block size past 32-bits.
Since your inputs are multiples of 32-bits, you can build a block cipher from these components in a way that does not require a specialized format preserving mode or algorithm. You essentially need a 32-bit and 64-bit block cipher. The components of AES or Blowfish can provide this.
Since AES instructions are available on both ARM and x86 processors and provide a secure, high speed, timing attack resistant implementation, building a cipher from AES components can be done in a way that can exploit these instructions. AES extends from 32-bits to 128 through the ShiftRows operation, which mixes the bytes of the 32-bit matrix multiplications so that 2 rounds provide full block diffusion.
We can describe a 32-bit cipher in terms of combined AES operations and other operations required to isolate the matrix multiplication from a full round, so an implementation utilizing AESNI instructions can use a similar description. A 64-bit variant requires little modification.
The AESENC instruction performs the ShiftRows and SubBytes operation, followed by MixColumns and AddKeys, as would a single AES round. If we "unshift" the input words prior to the instruction, we cancel out ShiftRows, generating a 4-way parallel operation we can use to build a 32-bit or 64-bit cipher, as below. For 32-bit inputs, proper key scheduling can allow 4-blocks to be encrypted in parallel, allowing fast CTR mode, or processing 4 independent inputs. A 64-bit version can provide 2-wide processing, and would also require an inter-word shift to diffuse the entire block, called prior to the "unshift":
Input to AES instruction is 4-word array, word(0 to 3)
variable n defines current round
key(n) defines a group of 4 32-bit identical subkeys for round n, or all 0 for n=empty
word(0) = 32-bit plaintext
AddKeys word(0-3), key(0)
iShift word(0-3)
AESENC word(0-3), key(1)
iShift word(0-3)
AESENC word(0-3), key(2)
...
iShift word(0-3)
AESENC word(0-3), key(n-1)
iShift word(0-3)
AESENCLAST word(0-3), key(empty)
AddKeys word(0-3), key(n)
32-bit ciphertext = word(0)
The 64-bit version would be mostly the same, except the size of the subkeys and plaintext spans 2-words, and the addition of a mixing operation prior to each iShift (inverse shiftrows) operation. This can be done by swapping bytes between each word. [ 0x00112233, 0xaabbccdd ] becomes [ 0xaa11cc33, 0x00bb22dd ], for example, which can be done in in a single SSE3 instruction without a branch.
For decryption the equivalent inverse is used, with InverseMixColumns (AESIMC instruction) used to generate decryption subkeys 1 through n-1. The keys are then placed in reverse order. ShiftRows is called in place of its inverse at the same step.
For either version the AES key schedule can be used, but the generated subkeys would need to be split into the size of the plaintext. Since less subkey material is mixed per round, the round count should be appropriate to diffuse the key material and resist attacks. The round count needs to be at least as many as AES for a given key size. I would suggest a minimum of 19 rounds for the 32-bit version, and 15 for the 64-bit version.
Nothing about this should be patented, or even patentable, as the basic building blocks are a cornerstone of modern cipher design, and this is simply a derivative of a public domain standard. As such it can be implemented on a variety of platforms from 8 to 64-bit, with a small codebase, and use specialized instructions for secure implementation.
With a proper round count, it should be as secure as the key size would provide, within the obvious limits placed on security by the block size. A different key schedule may provide better nonlinearity to the round subkeys, which may allow a similar security level with a lower round count, or a higher security level with the determined round count.
