Subject: about cast cfb64

From: <[email-masked]>
Date: 21 Nov 2002 04:01:37 -0000

/*
 The data is encrypted in CFB mode, with a CFB shift size equal to the
   cipher's block size.  The Initial Vector (IV) is specified as all
   zeros.  Instead of using an IV, OpenPGP prefixes a 10-octet string to
   the data before it is encrypted.  The first eight octets are random,
   and the 9th and 10th octets are copies of the 7th and 8th octets,
   respectively. After encrypting the first 10 octets, the CFB state is
   resynchronized if the cipher block size is 8 octets or less.  The
   last 8 octets of ciphertext are passed through the cipher and the
   block boundary is reset.
*/

this paragraph is come from rfc2440, now if i have the session key and the
ciphertext, how can i decrypt it?
below is what i have tried, but it does not work.
after the first call CAST_cfb64_encrypt, i can get the right 10 octet,
but the second is not right, where do i make some mistakes?
my environment is win2k+vc6.0+openssl
thanks
regards

CAST_KEY castkey;
unsigned char out[128], ivec[8];
int num=0;
memset(out, '\0', 128);
memset(ivec, '\0', 8);
CAST_set_key(&castkey, 16, sessionkey);
CAST_cfb64_encrypt(cipher, out, 10, &castkey, ivec, &num, CAST_DECRYPT);
num = 0;
memset(out, '\0', 128);
CAST_cfb64_encrypt(cipher+10, out, len-10,&castkey, cipher+2, &num,
CAST_DECRYPT);

________________
USTC Alumni Email System, http://mail.ustc.edu,  FREE Signup.

---

From: "Michael Young" <[email-masked]>
Date: Thu, 21 Nov 2002 13:05:54 -0500

The OpenSSL CAST CFB code is not handling the initialization
vector the way you want for partial-block lengths.  They
don't do a CFB "shift" for the partial block, but you want one.

After 10 bytes have been en/de-crypted, bytes 2-9 of the
ciphertext should appear in the "feedback register"
(called the "initialization vector" here), in that order.
That is, "ivec[0]" should contain "ciphertext[2]".

Unfortunately, it looks like their CFB code does not
"shift" the feedback register.  It leaves "ciphertext[2]"
in "ivec[2]", and so forth, so that ciphertext[9] ends
up in "ivec[1]". 

This is not necessarily wrong, it's just not what you
want.  They may want to be able to feed material piecemeal
without shifting.  For OpenPGP, you need the shift.

So, you need to shift "ivec" around 2 bytes.  Alternatively,
you could implement your own CFB support based on the
underlying CAST_encrypt function.

Good luck.

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: about cast cfb64
Date: Thu, 21 Nov 2002 13:05:54 -0500
Sender: [email-masked]

The OpenSSL CAST CFB code is not handling the initialization
vector the way you want for partial-block lengths.  They
don't do a CFB "shift" for the partial block, but you want one.

After 10 bytes have been en/de-crypted, bytes 2-9 of the
ciphertext should appear in the "feedback register"
(called the "initialization vector" here), in that order.
That is, "ivec[0]" should contain "ciphertext[2]".

Unfortunately, it looks like their CFB code does not
"shift" the feedback register.  It leaves "ciphertext[2]"
in "ivec[2]", and so forth, so that ciphertext[9] ends
up in "ivec[1]". 

This is not necessarily wrong, it's just not what you
want.  They may want to be able to feed material piecemeal
without shifting.  For OpenPGP, you need the shift.

So, you need to shift "ivec" around 2 bytes.  Alternatively,
you could implement your own CFB support based on the
underlying CAST_encrypt function.

Good luck.

Date: 21 Nov 2002 04:01:37 -0000
From: <[email-masked]>
To: [email-masked]
Subject: about cast cfb64
Sender: [email-masked]

  /*

CAST_KEY castkey;

________________

Date: Wed, 13 Nov 2002 11:37:20 +0100
From: Thomas Roessler <[email-masked]>
To: Michael Young <[email-masked]>
Cc: [email-masked]
Subject: Re: Reference for "IETF name space"?
Mail-Followup-To: Michael Young <[email-masked]>, [email-masked]
Organization: Palpatine's office.
Sender: [email-masked]

On 2002-11-04 11:01:23 -0500, Michael Young wrote:

>I see... I had interpreted the "IETF name space" as an existing 
>syntax defined by IETF, something like the DNS name space or the 
>ASN/OID name space.  David interprets it as a OpenPGP-specific 
>name space, with no specific structure yet defined, reserved for 
>assignment by the IETF/IANA. That's reasonable -- could one of the 
>RFC authors confirm that this is the intention?

Since I was the author of that particular language: Yes, that's the  
intention.  Everything which has an @ character in it is for users  
(since the DNS gives us a handy, decentralized way of avoiding chaos 
and collisions in this case).  If the @ character is not in there,  
there's right now no trivial way of avoiding collisions - short of  
registering notation tags with IANA (writing RFCs on them).

BTW, the idea was stolen from one of the SSH internet-drafts.

-- 
Thomas Roessler                        <[email-masked]>

From: The IESG <[email-masked]>
To: All IETF Working Groups: ;
Subject: Note Well Statement
Date: Thu, 07 Nov 2002 15:11:40 -0500
Sender: [email-masked]

>From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Reference for "IETF name space"?
Date: Mon, 4 Nov 2002 11:01:23 -0500
Sender: [email-masked]

> 2440bis specifies the IETF space as anything without a '@' sign in it,
> so "COMMENT" would be a perfectly valid notation tag.  Of course, it's
> not perfectly valid since that tag was never assigned by the IETF, but
> it is a tag that the IETF *could* use.  The IETF hasn't assigned any
> tags yet, so any tag without a '@' in it is currently an invalid tag.

I see... I had interpreted the "IETF name space" as an existing syntax
defined by IETF, something like the DNS name space or the ASN/OID name
space.  David interprets it as a OpenPGP-specific name space, with no
specific structure yet defined, reserved for assignment by the IETF/IANA.
That's reasonable -- could one of the RFC authors confirm that this
is the intention?

> There is no restriction as to what comes before the '@' (except that
> it is UTF-8) so a user can certainly use tags of the form
> "loginname+tagname1@...", "loginname+tagname2@...", etc.  It doesn't
> have to be a valid email address, though it's nice if it is.

Yes, this is a fine approach *if the domain owner approves*.  (Note
that "x+y@z" is a valid e-mail address in some domains.  It usually
reflects a login name "x", but it need not.)  My point wasn't that
a scheme couldn't be invented, simply that it's still really
a "DNS" name space, not a "user" space.  It's only a few dollars
a year to own a domain name, though, so it's not a big deal.

> I've actually been toying with the idea of disallowing any notation
> name that doesn't have a "@" in it for GnuPG (with an override for
> experts who presumably know what they are doing).

Given that the IETF name space is completely unallocated, I'd offer
another suggestion: change the RFC to reflect reality, and use
the *presence* of special character to mark the "IETF name space".
For example, tags starting with "$" could be the IETF space.
(David's keyserver analysis could give us a good idea what
characters haven't been used.)  Let the space without either
special character remain the free-for-all that it has become.

From: [email-masked]
To: [email-masked]
Subject: Re: Reference for "IETF name space"?
Date: Mon, 04 Nov 2002 11:00:52 -0500
Sender: [email-masked]

David wrote:

> 2440bis specifies the IETF space as anything without a '@' sign
> in it, so "COMMENT" would be a perfectly valid notation tag.
...
> > Lastly, does anyone happen to know whether/how PGP8 supports
>notations?
>
> Silently ignores them, though it does properly fail signature
> verification if the notation is marked critical.  That is RFC
> compliant behavior.
...

literally 'anything' is acceptable in the space, but with a minor
difference,
between gnupg and pgp as to the form of acceptablilty:

gnupg requires a ':', or it interprets it as an 'improper header',
but does not require any specific position for the ':', as long as it is 
anywhere on the same line.
{in this message, the ':' after the word 'version' has been omitted,
but the signature verifies ok, because there is a ':' in the emoticon of
the
version line.}

this message has a collection of the common notations, as well as an 
'anything' notation.

for purposes of uniformity and avoidance of confusion,
can gnupg allow the absence of the ':' ?

with Respect,

vedaal

-----BEGIN PGP SIGNATURE-----
Version OpenPGP {combined GnuPG/PGP :)  }
Comment: { Acts of Kindness better the World, and protect the Soul }
Comment: KeyID: 0x6A05A0B785306D25
Comment: Fingerprint: 96A6 5F71 1C43 8423  D9AE 02FD A711 97BA
Charset: Ancient Klingon ;)
Message id: only for those who care to know ;)
Anything: really 'anything' ;)

iQEVAwUBPcaVK2oFoLeFMG0lAQPd4wf7BrAQkVxB/6NI04XmAmkBxfXiYhgZuqBa
9PXpKpgJqMilPmhQtcQbOcULyMNpjsICmq9OMcJommFE0SEnCmHqWRw56DiPeCXt
JUqHSgC5PTVDjG0XdFyPSzta+sDqtW8kop1FtqP0c0Gk1UA67noIqHROKKad3KoI
/2fMcnH7gRGsowv+oXDYcEDYiY8MD7yofDs4xhZRlV3KiTJypRytEXuB94qV8VeZ
1uaXqGDw++3HnxR23wi7EUE9WubRWJudEO7rRSv5f5UT+lfriVebk0N6QdASp6pW
ANyT936jrN4hexKqKHllG4+2G0kuaVPeXR59pnXJJE5EraU7TCDaEA==
=mLwM
-----END PGP SIGNATURE-----

From: [email-masked]
To: [email-masked]
Subject: Re: Reference for "IETF name space"?
Date: Mon, 04 Nov 2002 10:50:45 -0500
Sender: [email-masked]

David wrote:

> 2440bis specifies the IETF space as anything without a '@' sign
> in it, so "COMMENT" would be a perfectly valid notation tag.
...
> > Lastly, does anyone happen to know whether/how PGP8 supports
>notations?
>
> Silently ignores them, though it does properly fail signature
> verification if the notation is marked critical.  That is RFC
> compliant behavior.
...

literally 'anything' is acceptable in the space, but with a minor
difference,
between gnupg and pgp as to the form of acceptablilty:

gnupg requires a ':', or it interprets it as an 'improper header',
but does not require any specific position for the ':', as long as it is 
anywhere on the same line.
{in this message, the ':' after the word 'version' has been omitted,
but the signature verifies ok, because there is a ':' in the emoticon of
the
version line.}

this message has a collection of the common notations, as well as an 
'anything' notation.

for purposes of uniformity and avoidance of confusion,
can gnupg allow the absence of the ':' ?

with Respect,

vedaal

-----BEGIN PGP SIGNATURE-----
Version: OpenPGP {combined GnuPG/PGP :)  }
Comment: { Acts of Kindness better the World, and protect the Soul }
Comment: KeyID: 0x6A05A0B785306D25
Comment: Fingerprint: 96A6 5F71 1C43 8423  D9AE 02FD A711 97BA
Charset: Ancient Klingon ;)
Message id: only for those who care to know ;)
Anything: really 'anything' ;)

iQEVAwUBPcaVK2oFoLeFMG0lAQPd4wf7BrAQkVxB/6NI04XmAmkBxfXiYhgZuqBa
9PXpKpgJqMilPmhQtcQbOcULyMNpjsICmq9OMcJommFE0SEnCmHqWRw56DiPeCXt
JUqHSgC5PTVDjG0XdFyPSzta+sDqtW8kop1FtqP0c0Gk1UA67noIqHROKKad3KoI
/2fMcnH7gRGsowv+oXDYcEDYiY8MD7yofDs4xhZRlV3KiTJypRytEXuB94qV8VeZ
1uaXqGDw++3HnxR23wi7EUE9WubRWJudEO7rRSv5f5UT+lfriVebk0N6QdASp6pW
ANyT936jrN4hexKqKHllG4+2G0kuaVPeXR59pnXJJE5EraU7TCDaEA==
=mLwM
-----END PGP SIGNATURE-----

Date: Sat, 2 Nov 2002 18:57:05 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Reference for "IETF name space"?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sat, Nov 02, 2002 at 05:18:53PM -0500, Michael Young wrote:

> From: "David Shaw" <[email-masked]>
> > There is no (simple) mechanism to register new tags.  There is a
> > rationale statement for this at the head of the RFC, under "IESG
> > Note".  Basically, the idea is that there can be subtle interactions
> > with unrestricted extensions of the standard, so this is a way to
> > force proposed extensions to go through the WG process to get wider
> > consideration.
> 
> The "subtle interactions" comment appears to be aimed at security
> (cryptographic) issues.  It makes less sense for clearly user-defined
> content like notations.  As long as the ownership of any given tag
> is clear (by using well-defined name spaces), I don't see a problem.

There can be subtle interactions even with non obviously cryptographic
issues.  For example, the PGP comment packet was dropped partially to
avoid the possibility of a rogue implementation leaking information
via that channel.  Even the MessageID armor header has a restriction
about how it is used to avoid the same problem.  It's quite possible
the barn door is already wide open on using notations to do the same
thing though.

But still, there isn't any problem with adding tags at any time for
any purpose to the user name space.  That's what it's there for.  Only
tags in the IETF name space needs some review before the tag is
accepted.

> But, this was a sidelight to my main question, which was...
> 
> > There are no notation tags in the IETF space yet.  However, a few
> 
> What *is* the IETF name space?  What does it look like?

Any tag that doesn't have a '@' sign in it is in the IETF name space.

> > months ago, I pulled together a list of all notations used on keys on
> > the keyserver net.  Perhaps unsurprisingly, nobody used the user name
> > space.  By far the most common notation used (87%) was "COMMENT".
> 
> By definition, any tag not in the user name space should be in the
> IETF name space.  If you say that there are none in this name space
> yet, you must know something about the structure of the IETF name
> space (to know that the existing tags don't fit).  Could you give an
> example of a valid name in the IETF space, and/or a reference to a
> definition of the IETF space?

2440bis specifies the IETF space as anything without a '@' sign in it,
so "COMMENT" would be a perfectly valid notation tag.  Of course, it's
not perfectly valid since that tag was never assigned by the IETF, but
it is a tag that the IETF *could* use.  The IETF hasn't assigned any
tags yet, so any tag without a '@' in it is currently an invalid tag.

> It certainly doesn't surprise me that there were no tags in the
> user name space.  It was only a few months ago that I noted that
> GnuPG rejected names with "@" in them.  (I suspect it was David
> who fixed it.  Thanks. :-)

You're welcome :)

The problem was that the notation naming scheme in GnuPG was
originally written to follow 2440.  The '@' scheme came in one of the
2440bis series.

> I should also note that the "user" name space is not particularly
> usable by ordinary folks.  According to the RFC, the owner of
> "[email-masked]" is the owner of "foo.bar".  Many users don't own domain
> names; at best, they "own" an e-mail address or login name at an ISP.
> Further, most own only one; even if the ISP delegated its space by
> e-mail address (as the RFC loosely suggests), each user would have
> only one tag.  Calling it a "user" name space (rather than a "DNS"
> name space) is misleading.

There is no restriction as to what comes before the '@' (except that
it is UTF-8) so a user can certainly use tags of the form
"loginname+tagname1@...", "loginname+tagname2@...", etc.  It doesn't
have to be a valid email address, though it's nice if it is.

> So, it doesn't surprise me that people have used simple, unstructured
> tag names, either ignoring conflict or assuming that human
> interpretation would be obvious and uncontroversial.

I suspect that very few people even knew there were reserved names at
all, since 2440 doesn't define this, and I doubt anyone using GnuPG
reads 2440bis (or 2440 for that matter) before starting. ;)

I've actually been toying with the idea of disallowing any notation
name that doesn't have a "@" in it for GnuPG (with an override for
experts who presumably know what they are doing).

> Lastly, does anyone happen to know whether/how PGP8 supports notations?

Silently ignores them, though it does properly fail signature
verification if the notation is marked critical.  That is RFC
compliant behavior.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Reference for "IETF name space"?
Date: Sat, 2 Nov 2002 17:18:53 -0500
Sender: [email-masked]

From: "David Shaw" <[email-masked]>
> There is no (simple) mechanism to register new tags.  There is a
> rationale statement for this at the head of the RFC, under "IESG
> Note".  Basically, the idea is that there can be subtle interactions
> with unrestricted extensions of the standard, so this is a way to
> force proposed extensions to go through the WG process to get wider
> consideration.

The "subtle interactions" comment appears to be aimed at security
(cryptographic) issues.  It makes less sense for clearly user-defined
content like notations.  As long as the ownership of any given tag
is clear (by using well-defined name spaces), I don't see a problem.

But, this was a sidelight to my main question, which was...

> There are no notation tags in the IETF space yet.  However, a few

What *is* the IETF name space?  What does it look like?

> months ago, I pulled together a list of all notations used on keys on
> the keyserver net.  Perhaps unsurprisingly, nobody used the user name
> space.  By far the most common notation used (87%) was "COMMENT".

By definition, any tag not in the user name space should be in the
IETF name space.  If you say that there are none in this name space
yet, you must know something about the structure of the IETF name
space (to know that the existing tags don't fit).  Could you give an
example of a valid name in the IETF space, and/or a reference to a
definition of the IETF space?

It certainly doesn't surprise me that there were no tags in the
user name space.  It was only a few months ago that I noted that
GnuPG rejected names with "@" in them.  (I suspect it was David
who fixed it.  Thanks. :-)

I should also note that the "user" name space is not particularly
usable by ordinary folks.  According to the RFC, the owner of
"[email-masked]" is the owner of "foo.bar".  Many users don't own domain
names; at best, they "own" an e-mail address or login name at an ISP.
Further, most own only one; even if the ISP delegated its space by
e-mail address (as the RFC loosely suggests), each user would have
only one tag.  Calling it a "user" name space (rather than a "DNS"
name space) is misleading.

So, it doesn't surprise me that people have used simple, unstructured
tag names, either ignoring conflict or assuming that human
interpretation would be obvious and uncontroversial.

Lastly, does anyone happen to know whether/how PGP8 supports notations?

Thanks again!

Date: Sat, 2 Nov 2002 07:40:54 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Reference for "IETF name space"?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Nov 01, 2002 at 06:01:01PM -0500, Michael Young wrote:

> Section 5.2.3.16, Notation Data, explains that tags fall into one of two
> name spaces: the "IETF name space" and a "user name space".
> 
> What IETF name space is this?  If it is the URN namespace for IETF
> documents, described by RFC2648, how is it applied here?  If it's
> something else, could someone provide me a reference?  Further,
> could someone offer an example of a notation tag in the IETF space?

There is no (simple) mechanism to register new tags.  There is a
rationale statement for this at the head of the RFC, under "IESG
Note".  Basically, the idea is that there can be subtle interactions
with unrestricted extensions of the standard, so this is a way to
force proposed extensions to go through the WG process to get wider
consideration.

There are no notation tags in the IETF space yet.  However, a few
months ago, I pulled together a list of all notations used on keys on
the keyserver net.  Perhaps unsurprisingly, nobody used the user name
space.  By far the most common notation used (87%) was "COMMENT".

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Reference for "IETF name space"?
Date: Fri, 1 Nov 2002 18:01:01 -0500
Sender: [email-masked]

Section 5.2.3.16, Notation Data, explains that tags fall into one of two
name spaces: the "IETF name space" and a "user name space".

What IETF name space is this?  If it is the URN namespace for IETF
documents, described by RFC2648, how is it applied here?  If it's
something else, could someone provide me a reference?  Further,
could someone offer an example of a notation tag in the IETF space?

Back in 1999, Thomas Roessler suggested
>    Note: New notation data names in the IETF name space may be
>    registered by sending e-mail to
>    <[email-masked]>.  The listing of current
>    values may be obtained by sending e-mail to
>    <[email-masked]>.

This doesn't seem to have happened.  Is there another registry,
or is this just a free-for-all?

Thanks for any information you can provide!