Re: HMAC and timing based attacks - ticket #14445

2010-10-12 Thread Luke Plant 
On Tue, 2010-10-12 at 15:27 +1300, Nick Phillips wrote:

> First of all I should say that I'm no crypto expert, but I'm worried
> about the key. Inclusion of fixed strings in a key for this type of use
> rings alarm bells, as does the use of an ASCII key (albeit 50 chars
> rather than the 20 recommended for use with SHA1 in HMAC), and the fact
> that in reality, it's never going to get refreshed.

The fixed strings are used to make the keys unique per application - see
below for what the keys are like that actually end up being used.

> On the key strength, I notice that RFC2104 recommends the hashing of the
> key using the underlying hash function if the supplied key length is
> greater than the hash output length. It would appear that this will
> usually be the case, so Python's hmac module will probably be doing this
> for us. However, there's rather a lot of "implicit" and "probably" in
> that. And it would be perfectly possible that someone would update the
> hash function used at some later date without realising the assumptions
> that are being made. Might it not at least be a better idea to
> explicitly ensure that the combination of fixed string and SECRET_KEY is
> longer than the hash output length, and to hash the resulting string
> before calling hmac.new?

AFAICS the HMAC module does all this.  From hmac:

class HMAC:  
"""RFC 2104 HMAC class.  Also complies with RFC 4231...
"""
# ...

def __init__(self, key, msg=None, digestmod=None):
# ...
if len(key) > blocksize:   
key = self.digest_cons(key).digest()   
# ...

So it is explicit - the hmac module does RFC 2104 for us, that's what we
are relying on it for. If this module *stops* doing this, then all the
existing MACs generated will be broken, so backwards compatibility means
it will carry on doing so. We should let this module do our crypto for
us as much as possible.

> I do seem to remember there being apparently good reasons for not using
> the same secret key throughout, although I can't remember what they
> were. Given the need for distinct keys for different purposes (I'm
> assuming there really is still such a need, for now), it seems to me
> that explicitly having separate keys in settings.py for each purpose
> would be preferable (either as separate entries or by chopping a much
> longer SECRET_KEY into substrings). That then makes me wonder whether
> there's any real benefit to storing the key in settings anyway - perhaps
> we could come up with an alternative that would both manage separate
> keys for each requirement, and actually allow the keys to be refreshed
> without invalidating existing otherwise-valid HMACs?

We need different keys for different purposes to stop a signature of a
value by one area of the code being used against another area.  For
example, if we are effectively handing out HMAC(key,
user_controlled_string) in a comment form, and require HMAC(key,
users_email_address+timeout) in the password reset mechanism, an
attacker might be able to use the first to produce the HMAC required in
the second. They might not, of course, depending on exactly how much
control the user has over the user_controlled_string, but by using
different keys we avoid the possibility altogether.

Since we are effectively using
SHA1(different_fixed_string_for_each_application + SECRET_KEY) as the
key, it isn't obvious to me that using
SHA1(entirely_different_random_string_for_each_application) is really
any different, or really that much superior.  Even if it was preferable
to use the latter, we can't do that easily with backwards compatibility
- we would need to generate new random strings for each key needed and
insert them into settings.py.

As for key rotating/refreshing - that would also (probably) be
desirable, but it would be significantly more work. There is no way to
change the key without invalidating existing HMACs (that's the whole
point), so you would effectively have something like a list of
SECRET_KEYS, where the first is the one used for generating HMACs, but
each is tried for verifying them.  We had some discussion about this
before. See the bottom of http://code.djangoproject.com/wiki/Signing

However, I don't think we should delay this change for the sake of that
ideal.  We may actually want an API that allows not only different keys
but different MAC algorithms (in fact our code base would already use
that, since in one case we truncate the HMAC to produce a smaller URL).
But again, that's a larger bit of work which could be done later without
compatibility problems as it would generate the same MACs by default.

Thanks,

Luke

-- 
"He knows the way I take: when he has tried me, I shall come forth 
as gold" (Job 23:10).

Luke Plant || http://lukeplant.me.uk/


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-d

8040 SlugField format not enforced - fixed, closed an "ready for checkin" since two years

2010-10-12 Thread Sebastian 
Hello,
the ticket "SlugField format not enforced" is fixed, closed an "ready
for checkin" since two years. What can I do?

Regards, Sebastian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 8040 SlugField format not enforced - fixed, closed an "ready for checkin" since two years

2010-10-12 Thread Luke Plant 
On Tue, 2010-10-12 at 04:21 -0700, Sebastian wrote:
> Hello,
> the ticket "SlugField format not enforced" is fixed, closed an "ready
> for checkin" since two years. What can I do?

It is 'closed: fixed', which means the fix entered to the code base -
two years ago, as you say.  There is nothing left to do, so I don't see
what the problem is.

Luke

-- 
"He knows the way I take: when he has tried me, I shall come forth 
as gold" (Job 23:10).

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 8040 SlugField format not enforced - fixed, closed an "ready for checkin" since two years

2010-10-12 Thread Sebastian 
Hello,
I investigated a bit further, it was commited with r8477
http://code.djangoproject.com/changeset/8477

But somewhere it got lost. In the current definition for SlugField I
can only find a validation for max_length:
http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/__init__.py#L1000

Sebastian

On 12 Okt., 13:34, Luke Plant  wrote:
> On Tue, 2010-10-12 at 04:21 -0700, Sebastian wrote:
> > Hello,
> > the ticket "SlugField format not enforced" is fixed, closed an "ready
> > for checkin" since two years. What can I do?
>
> It is 'closed: fixed', which means the fix entered to the code base -
> two years ago, as you say.  There is nothing left to do, so I don't see
> what the problem is.
>
> Luke
>
> --
> "He knows the way I take: when he has tried me, I shall come forth
> as gold" (Job 23:10).
>
> Luke Plant ||http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 8040 SlugField format not enforced - fixed, closed an "ready for checkin" since two years

2010-10-12 Thread Peter Baumgartner 
It just moved. See:

http://code.djangoproject.com/browser/django/trunk/django/forms/fields.py#L924
http://code.djangoproject.com/browser/django/trunk/django/core/validators.py#L122

-- Pete

On Tue, Oct 12, 2010 at 8:44 AM, Sebastian  wrote:
> Hello,
> I investigated a bit further, it was commited with r8477
> http://code.djangoproject.com/changeset/8477
>
> But somewhere it got lost. In the current definition for SlugField I
> can only find a validation for max_length:
> http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/__init__.py#L1000
>
> Sebastian
>
> On 12 Okt., 13:34, Luke Plant  wrote:
>> On Tue, 2010-10-12 at 04:21 -0700, Sebastian wrote:
>> > Hello,
>> > the ticket "SlugField format not enforced" is fixed, closed an "ready
>> > for checkin" since two years. What can I do?
>>
>> It is 'closed: fixed', which means the fix entered to the code base -
>> two years ago, as you say.  There is nothing left to do, so I don't see
>> what the problem is.
>>
>> Luke
>>
>> --
>> "He knows the way I take: when he has tried me, I shall come forth
>> as gold" (Job 23:10).
>>
>> Luke Plant ||http://lukeplant.me.uk/
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 8040 SlugField format not enforced - fixed, closed an "ready for checkin" since two years

2010-10-12 Thread Luke Plant 
On Tue, 2010-10-12 at 07:44 -0700, Sebastian wrote:
> Hello,
> I investigated a bit further, it was commited with r8477
> http://code.djangoproject.com/changeset/8477
> 
> But somewhere it got lost. In the current definition for SlugField I
> can only find a validation for max_length:
> http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/__init__.py#L1000

It does look like something has been lost from the models SlugField (not
the forms SlugField), probably the default_validators attribute. Please
open a new ticket, preferably with a test that shows the problem and/or
a fix.

Thanks,

Luke

-- 
"He knows the way I take: when he has tried me, I shall come forth 
as gold" (Job 23:10).

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 8040 SlugField format not enforced - fixed, closed an "ready for checkin" since two years

2010-10-12 Thread Sebastian 
I am sorry - you are right, I just found the error in my code
sorry, sorry, sorry and thanks for the fast feedback!

Sebastian

On 12 Okt., 16:49, Peter Baumgartner  wrote:
> It just moved. See:
>
> http://code.djangoproject.com/browser/django/trunk/django/forms/field...http://code.djangoproject.com/browser/django/trunk/django/core/valida...
>
> -- Pete
>
>
>
>
>
>
>
> On Tue, Oct 12, 2010 at 8:44 AM, Sebastian  wrote:
> > Hello,
> > I investigated a bit further, it was commited with r8477
> >http://code.djangoproject.com/changeset/8477
>
> > But somewhere it got lost. In the current definition for SlugField I
> > can only find a validation for max_length:
> >http://code.djangoproject.com/browser/django/trunk/django/db/models/f...
>
> > Sebastian
>
> > On 12 Okt., 13:34, Luke Plant  wrote:
> >> On Tue, 2010-10-12 at 04:21 -0700, Sebastian wrote:
> >> > Hello,
> >> > the ticket "SlugField format not enforced" is fixed, closed an "ready
> >> > for checkin" since two years. What can I do?
>
> >> It is 'closed: fixed', which means the fix entered to the code base -
> >> two years ago, as you say.  There is nothing left to do, so I don't see
> >> what the problem is.
>
> >> Luke
>
> >> --
> >> "He knows the way I take: when he has tried me, I shall come forth
> >> as gold" (Job 23:10).
>
> >> Luke Plant ||http://lukeplant.me.uk/
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: HMAC and timing based attacks - ticket #14445

2010-10-12 Thread Ian Clelland 
On Mon, Oct 11, 2010 at 7:27 PM, Nick Phillips wrote:

> First of all I should say that I'm no crypto expert, but I'm worried
> about the key. Inclusion of fixed strings in a key for this type of use
> rings alarm bells, as does the use of an ASCII key (albeit 50 chars
> rather than the 20 recommended for use with SHA1 in HMAC), and the fact
> that in reality, it's never going to get refreshed.
>
> On the key strength, I notice that RFC2104 recommends the hashing of the
> key using the underlying hash function if the supplied key length is
> greater than the hash output length. It would appear that this will
> usually be the case, so Python's hmac module will probably be doing this
> for us. However, there's rather a lot of "implicit" and "probably" in
> that.


I think that's more than just a recommendation -- the key for the underlying
hash function needs to be of a certain size; there's not really an option to
just let it remain longer. The text from the RFC reads

   Applications that use keys longer than B bytes will first hash the key using
   H and then use the resultant L byte string as the actual key to HMAC.

And Python's hmac.py definitely does that; if the key is longer than the
block size, it hashes it, and if it is shorter, then it pads it with zeroes.
(That bit of code hasn't changed since at least Python 2.4)



> And it would be perfectly possible that someone would update the
> hash function used at some later date without realising the assumptions
> that are being made. Might it not at least be a better idea to
> explicitly ensure that the combination of fixed string and SECRET_KEY is
> longer than the hash output length, and to hash the resulting string
> before calling hmac.new?
>

That's a different issue -- if the key is *shorter* than the block size,
then it has to be padded, which is what hmac.py does (again, mandated by
RFC). Even if we pre-hashed the key to get it to exactly the block size in
this case, we wouldn't actually be gaining any entropy.

As I can tell, given the HMAC algorithm, if you were to swap, say, a 128-bit
hash function with a 256-bit hash function, but kept the same 128-bit key,
then the resulting MAC wouldn't be any less secure than the original. You
could certainly improve it by going to a longer key at that point, but you
don't have to. Perhaps the best thing for Django to do would be to issue a
warning in that case that the key is shorter than it could be.

-- 
Regards,
Ian Clelland


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

It is real to add ticket #8054 to 1.3 milestone?

2010-10-12 Thread alekam 
Hi All,

I found very useful ticket #8054. This ticket has accepted status and
assigned to brosher about 2 years. The problem describes on ticket
detail page and in the wiki http://code.djangoproject.com/wiki/ListColumns
The ticket has patch witch passes all existing regression tests and I
plan to write unit tests for it.
It is real to add ticket #8054 to 1.3 milestone?


Cheers,

Alex Kamedov

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: It is real to add ticket #8054 to 1.3 milestone?

2010-10-12 Thread Gabriel Hurley 
Hi alekam,

This is certainly the kind of ticket that we want to deal with in 1.3
since it's been around so long and deferred a couple times. Starting
the discussion here is definitely the right way to make it happen.

That said, at the very least it needs a thorough code review, a full
set of tests, and good documentation before it can be included.

I'm not personally sold on the way the functionality is implemented,
but I'd have to think on what would be preferable. I'm sure others
will have stronger opinions on it one way or the other.

All the best,

- Gabriel

On Oct 12, 9:47 am, alekam  wrote:
> Hi All,
>
> I found very useful ticket #8054. This ticket has accepted status and
> assigned to brosher about 2 years. The problem describes on ticket
> detail page and in the wikihttp://code.djangoproject.com/wiki/ListColumns
> The ticket has patch witch passes all existing regression tests and I
> plan to write unit tests for it.
> It is real to add ticket #8054 to 1.3 milestone?
>
> Cheers,
>
> Alex Kamedov

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Translating Django's documentation

2010-10-12 Thread Ian Lewis 
Hi all,

I am a member of the Japanese Django community which is maintaining a
somewhat(read very) outdated version of the Django documentation here:
http://djangoproject.jp/doc/ja/1.0/

I'm trying to kickstart a project to
update the documentation and in looking around I noticed that on Django's
homepage the documentation's URL includes the language code. I was
wondering, is there is an official way to submit translations for Django's
documentation? Is there currently a way to link or help direct users from
Django's site to the proper resources in the their language?

-- 
Ian

http://www.ianlewis.org/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Translating Django's documentation

2010-10-12 Thread Russell Keith-Magee 
On Wed, Oct 13, 2010 at 10:20 AM, Ian Lewis  wrote:
> Hi all,
> I am a member of the Japanese Django community which is maintaining a
> somewhat(read very) outdated version of the Django documentation
> here: http://djangoproject.jp/doc/ja/1.0/
> I'm trying to kickstart a project to update the documentation and in looking
> around I noticed that on Django's homepage the documentation's URL includes
> the language code. I was wondering, is there is an official way to submit
> translations for Django's documentation? Is there currently a way to link or
> help direct users from Django's site to the proper resources in the their
> language?

Not *quite* yet.

The URL you've noticed is forward planning -- translations of the
documentation have always been on the nice-to-have list, so we've
planned for future expansion. At the moment, however, there is only
the english translation, and we don't really have the facilities to
handle alternate languages.

There are a bunch of modifications that we want to make to
docs.djangoproject.com, and providing support for other languages is
part of those improvements. Some recent additions to Sphinx should
make it much easier to manage this process.

If you want to help out set up the infrastructure to make this happen,
there was a recent call for volunteers on the Django Software
Foundation's members and volunteers list [1]; if you jump on that list
now, it's not too late to register your interest in helping out (ok..
the deadline has passed, but we're not going to pass up any offer of
volunteer help).

[1] http://groups.google.com/group/dsf-members

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Translating Django's documentation

2010-10-12 Thread Ian Lewis 
On Wed, Oct 13, 2010 at 11:32 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Wed, Oct 13, 2010 at 10:20 AM, Ian Lewis  wrote:
> > Hi all,
> > I am a member of the Japanese Django community which is maintaining a
> > somewhat(read very) outdated version of the Django documentation
> > here: http://djangoproject.jp/doc/ja/1.0/
> > I'm trying to kickstart a project to update the documentation and in
> looking
> > around I noticed that on Django's homepage the documentation's URL
> includes
> > the language code. I was wondering, is there is an official way to submit
> > translations for Django's documentation? Is there currently a way to link
> or
> > help direct users from Django's site to the proper resources in the their
> > language?
>
> Not *quite* yet.
>
> The URL you've noticed is forward planning -- translations of the
> documentation have always been on the nice-to-have list, so we've
> planned for future expansion. At the moment, however, there is only
> the english translation, and we don't really have the facilities to
> handle alternate languages.
>
> There are a bunch of modifications that we want to make to
> docs.djangoproject.com, and providing support for other languages is
> part of those improvements. Some recent additions to Sphinx should
> make it much easier to manage this process.
>
> If you want to help out set up the infrastructure to make this happen,
> there was a recent call for volunteers on the Django Software
> Foundation's members and volunteers list [1]; if you jump on that list
> now, it's not too late to register your interest in helping out (ok..
> the deadline has passed, but we're not going to pass up any offer of
> volunteer help).
>
> [1] http://groups.google.com/group/dsf-members
>
> Yours,
> Russ Magee %-)



Ok,  I wasn't aware of the other list.  I send a request for membership.

Thanks,


-- 
Ian

http://www.ianlewis.org/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Translating Django's documentation

2010-10-12 Thread Jacob Kaplan-Moss 
On Tue, Oct 12, 2010 at 9:32 PM, Russell Keith-Magee
 wrote:
> There are a bunch of modifications that we want to make to
> docs.djangoproject.com, and providing support for other languages is
> part of those improvements. Some recent additions to Sphinx should
> make it much easier to manage this process.
>
> If you want to help out set up the infrastructure to make this happen,
> there was a recent call for volunteers on the Django Software
> Foundation's members and volunteers list [1]; if you jump on that list
> now, it's not too late to register your interest in helping out (ok..
> the deadline has passed, but we're not going to pass up any offer of
> volunteer help).

Another way to help: I'm currently working on a cleanup and refactor
of the djangoproject.com website code, including docs. This'll go live
along with a new server we're moving to -- soon, no, really this time!

The current state-of-the-art is in the somewhat-badly-named
"community_redux" branch on my Github account:
http://github.com/jacobian/djangoproject.com/tree/community_redux, and
I would *gladly* take input and/or patches into how to start adding
multi-language support.

There are some tricky problems to solve -- most notably the issue of
tracking which bits of content have been translated into which
languages and how up-to-date with the original English docs those are
-- but I would be thrilled to see someone start working on these
things.

(Eventually that code'll migrate back to SVN and follow our normal
contribution process, but for some legacy reasons I can't actually
commit this stuff back to SVN without breaking the current site at the
moment. Just one more thing to fix on the new server...)

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: HMAC and timing based attacks - ticket #14445

2010-10-12 Thread Nick Phillips 
On Tue, 2010-10-12 at 12:03 +0100, Luke Plant wrote:

> The fixed strings are used to make the keys unique per application - see
> below for what the keys are like that actually end up being used.

I realise that, I just couldn't remember exactly why that was
necessary... but you answered that below.


> AFAICS the HMAC module does all this.  From hmac:
> 
> class HMAC:  
> """RFC 2104 HMAC class.  Also complies with RFC 4231...
> """
> # ...
> 
> def __init__(self, key, msg=None, digestmod=None):
> # ...
> if len(key) > blocksize:   
> key = self.digest_cons(key).digest()   
> # ...
> 
> So it is explicit - the hmac module does RFC 2104 for us, that's what we
> are relying on it for. If this module *stops* doing this, then all the
> existing MACs generated will be broken, so backwards compatibility means
> it will carry on doing so. We should let this module do our crypto for
> us as much as possible.

Absolutely - I hadn't had a chance to check the hmac module, but given
the fact that it does pre-hash or pad as recommended (and assuming it
will continue to do so), that's fine.


> Since we are effectively using
> SHA1(different_fixed_string_for_each_application + SECRET_KEY) as the
> key, it isn't obvious to me that using
> SHA1(entirely_different_random_string_for_each_application) is really
> any different, or really that much superior.  Even if it was preferable
> to use the latter, we can't do that easily with backwards compatibility
> - we would need to generate new random strings for each key needed and
> insert them into settings.py.

Personally, I'd be looking for reassurance from a "crypto expert" at
this point. I'd agree that it would appear that any problem is not
obvious, but then neither would I expect it to be so. I would not be at
all surprised if the combination of being able to control the message,
and being able to get an HMAC of it with two different but related keys
enables an attack, and some googling for "related key attack on hmac"
would seem to support this possibility (although as I said, I'm no
expert, and I don't have time to look into it in detail).


> As for key rotating/refreshing - that would also (probably) be
> desirable, but it would be significantly more work. There is no way to
> change the key without invalidating existing HMACs (that's the whole
> point), so you would effectively have something like a list of
> SECRET_KEYS, where the first is the one used for generating HMACs, but
> each is tried for verifying them.  We had some discussion about this
> before. See the bottom of http://code.djangoproject.com/wiki/Signing

Yes, that's the kind of thing I was thinking of.


> However, I don't think we should delay this change for the sake of that
> ideal.

Makes sense. What you're doing is clearly an improvement, and one with
no cost to the user involved in making the change, so...


Cheers,


Nick
-- 
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.