Just one off-the-cuff alternative representation, with some properties
that might be useful to you...
If this representation is internal to your system, the encrypted data is
small enough that you'll fit it in RAM, and you only have a small number
of different encryption methods, and your crypto library doesn't mind...
then what about representing both the method and data in a single Racket
string (or byte-string), and also using that string as the
representation in database, network, and anywhere else?
For example, in "1:fjeDo83Lks8dfhH":
* the character(s) for the number "1" means the method of AES with CBC
(later methods get their own number, within your system).
* the character ":" both terminates the method number, and also
indicates base-64 encoding of the cypher text (if you ever add a
different encoding, such as a raw byte string, you can use a different
non-digit character other than ":" for it); and
* the rest is the cypher text, in that encoding, from that method.
(Or, for a little extra debugging benefit, additionally prefix a
constant searchable string that represents this particular encoding,
like "yaee1:fjeDo83Lks8dfhH", where "yaee" is the name of your format,
"yet another encryption envelope".)
Or, if you don't mind spending a few more characters, or if there will
be interchange with other systems (which might not appreciate that
serial number system of method encoding), a very programmer-intuitive
format: "aes256:cbc:base64:fjeDo83Lks8dfhH".
Both of those formats are ASCII strings that can be stored and
transmitted as-is pretty much everywhere, encoded&decoded trivially, and
the format is probably recognizable and readable to a programmer who is
debugging.
There is a small possible efficiency consideration when using this
format: let's say that a different way would let you use the raw output
representation of whatever encryption library/device you use, but this
way requires you to do additional encodings copy, and you can't work
around that with cleverness, and the efficiency difference matters.
(For example, you have fast encryption hardware, but a necessary extra
copy operation to get your prefix on the string is very large or very
many, and that matters in this particular system.) Perhaps, in most
real systems, such an extra copy would be in the noise, with numerous
better places to improve efficiency.
Ideally (and probably), whatever base64 or crypto library you're using
can work from the RAM representation, and with the prefix skipped,
without introducing an additional substring copy.
(BTW, if regulatory compliance and privacy&security auditing is a
consideration for this system, then using a format that's either
pre-approved, or is very simple to document and understand, might be a
consideration. Even in a very simple approach, there are details that
might be relevant, such as your implementation of the format has to be
careful about data copies at a low level, which some other
implementation handles already. Details can be nonobvious but some
parties might care, like, if you changed what encryption method you used
at a known point in time, then that might leak a tiny bit of information
about records (maybe e.g., it could be used to help identify individuals
in a data dump that encrypts or omits explicit identification, or leak
how much a particular individual has been to the doctor since that known
point in time even if all timepoints are encrypted and there's no
database record IDs leaking that).
(In any case, I'd try to avoid XML for the above purpose, unless
mandated. XML is overpowered for that purpose. I've seen systems use
XML for the above purpose alone, which is extra system complexity, extra
time and space costs, and perhaps more programming work. I've also seen
design problems in this sort of thing, which I suspect were obscured
from the programmer by the representational bulk and programming work of
XML. XML might be a very appropriate encoding within the encrypted
text, however, especially if doing interchange of important data.)
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
