Kai,
On Mon, Jan 18, 2010 at 5:55 AM, Kai Moonbourn via RT
<bug-Crypt-VERPString@rt.cpan.org> wrote:
Show quoted text> Mon Jan 18 08:55:08 2010: Request 53794 was acted upon.
> Transaction: Ticket created by epimetreus@fastmail.fm
> Queue: Crypt-VERPString
> Subject: Docs bug
> Broken in: (no value)
> Severity: (no value)
> Owner: Nobody
> Requestors: epimetreus@fastmail.fm
> Status: new
> Ticket <URL:
http://rt.cpan.org/Ticket/Display.html?id=53794 >
Thanks for bringing this to my attention.
Show quoted text> What exactly does "Encrypt and encode fixed-length records for VERP" mean?
The purpose of this module is to prepare a string of data to be
appended to the local-part of an email address using D.J. Bernstein's
Variable Envelope Return Path convention. The purpose of a VERP string
is to uniquely identify an email message should it bounce and/or get
divorced from its message-ID. The purpose of encrypting the string is
to keep its contents secret from the recipient while not requiring the
sender to retain a large number of nonce tokens.
Show quoted text> As I understand it, you pass encoder an arbitrary list of scalars, and
> it encodes them into a single string suitable for embedding in a
> return-path.... but what are the limitations?
>
> It would be helpful if the docs explained the following:
>
> -Input limitations; what characters aren't accepted input; minimum
> and/or maximum list/item lengths
> -What 'fixed-length' refers to, precisely - the example shows 3 items in
> the encrypt() list, which are not all of equal length, so what is it
> talking about?
> -Etc.
The "fixed-lengthness" of the string is due to passing in a pack()
format to the constructor. I agree that is not accurate, as those may
indeed have variable length (now that I look, even the example shows
that with the format "Na*"). The contents you can encrypt therefore
have the same properties as pack(). A more accurate description would
be fixed-format, as you give the pack format once to the constructor
and values to fill it with each call to encrypt(), This brings me to
following point.
The encrypt() method takes as its first argument an integer as an
initialization vector. Each subsequent argument corresponds to a field
in the pack() format. In the case of that example, N is a
network-endian 32-bit integer and a* is (in fact variable-length)
null-padded arbitrary binary data. Therefore the arguments 12345 and
'hi i am a payload!' correspond to the format 'Na*' given in the
constructor.
Show quoted text> Clarification would be nice.
You are right, it would be nice. This module, however, is a low
priority for me. I have not needed what it does for almost as long as
I've had it on CPAN. It is worth noting that since I uploaded it, one
of its dependencies has changed somehow, as I have begun receiving
automated reports of failed tests when I hadn't before.
It is also worth noting that even if I did need it, I probably would
employ a different strategy altogether. First, managing a big
dictionary of nonces isn't as big of a deal as it used to be, as
storage is orders of magnitude cheaper than it was five years ago.
Second, a cipher block chain (or really any kind of nontrivial block
crypto) requires a junk block at the beginning otherwise it's useless,
so the length of the encrypted output is always pad(msg)+1*blocksize.
Combine that with base32 encoding and you get one big-ass identifier,
which you may not even be able to use, due to restrictions on certain
SMTP implementations. Finally, I'm not sure but I've always wondered
that if the internal structure of such a small encrypted segment were
known it would permit cryptanalysis given a large enough sample. It
could very well have been a lot of effort for not very much gain.
I reiterate; I wouldn't use this strategy if I needed to accomplish
this objective again.
Regards,
--
Dorian Taylor
http://doriantaylor.com
tel:+1-604-723-5755
