Endianness issues with GPG

[malsyned@dennisx.cif.rochester.edu]

>    Having checked out that the binary files produced
> by GPG-encrypting a file without ASCII armor in a
> little endian platform can be decrypted in a big
> endian one, without any other provisos (i.e. my
> assumption was wrong) I wonder if anyone could provide
> a rigorous justification for this? Please, forgive me
> and my ignorance if this is a trivial issue.

Most of the data in any OpenPGP message is treated as a sequence of octets 
(8-bit bytes), and so there wouldn't be any more endianness trouble with 
those parts of the message than their would with everyone's favorite type 
of octet stream, the ASCII text file.

Some chunks of data in an OpenPGP message, however, do deal in multi-byte
chunks, and so endianness issues do become relavent.  However, the OpenPGP
standard, RFC 2440, disambiguates this issue by requiring all multi-byte
data to be in big-endian.  Here are some of the relavent sections from the
RFC:

---
3.1. Scalar numbers

   Scalar numbers are unsigned, and are always stored in big-endian
   format. Using n[k] to refer to the kth octet being interpreted, the
   value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a
   four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) +
   n[3]).

3.2. Multi-Precision Integers

   Multi-Precision Integers (also called MPIs) are unsigned integers
   used to hold large integers such as the ones used in cryptographic
   calculations.

   An MPI consists of two pieces: a two-octet scalar that is the length
   of the MPI in bits followed by a string of octets that contain the
   actual integer.

   These octets form a big-endian number; a big-endian number can be
   made into an MPI by prefixing it with the appropriate length.
---

Most standards, especially Internet RFCs, address the endianness issue so 
that crossplatform interoperability can be ensured.  I hope that clears up 
your confusion.

--Dennis Lambe