OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] Possible 1.1 (and 1.0) errata


Colleagues -
Based on my initial analysis and John's further corrections/comments, it is
my belief that we only need to correct a very minor aspect of the write-up,
namely changing < 128/160 bits to <= 128/160 bits.

If anyone feels differently, please let me know. Otherwise, I will create a
new errata item to this effect.

Co-chairs -
Assuming that the correction to this errata is as I explained above (i.e.,
changing a < to a <= ), can we make this change to core without upsetting
the process?

Thanks,
Jahan


----------------
Jahan Moreh
Chief Security Architect
310.286.3070

> -----Original Message-----
> From: Linn, John [mailto:jlinn@rsasecurity.com]
> Sent: Tuesday, August 05, 2003 12:11 PM
> To: 'jmoreh@sigaba.com'; Scott Cantor; SAML
> Subject: RE: [security-services] Possible 1.1 (and 1.0) errata
>
>
> I think this result is almost right, but question an aspect of
> the analysis.
> The "almost right" part first: the "less than" components should be "less
> than or equal to", assuming that the intent is to allow 128-bit
> and 160-bit
> values respectively rather than requiring something slightly larger; the
> probability that one 160-bit random value matches the next should
> be exactly
> 2^-160, not less.  The first trial fixes the value against which
> the second
> independent sample will be compared, and there are 2^160 possible values.
>
> WRT the analysis, it's easier (given enough operations and their
> accumulated
> history) to find a result collision between some pair of hash
> inputs than to
> find a match against a specific fixed output.  This corresponds to the
> result that 2^80 operations can be expected to yield *some*
> collision for a
> 160-bit hash function, but doesn't mean that the probability that two
> initial trials, taken in isolation, will match with a probability
> as "high"
> as 2^-80.
>
> --jl
>
> -----Original Message-----
> From: Jahan Moreh [mailto:jmoreh@sigaba.com]
> Sent: Tuesday, August 05, 2003 1:41 PM
> To: Scott Cantor; SAML
> Subject: RE: [security-services] Possible 1.1 (and 1.0) errata
>
>
> Scott -
> This is the text in 1.1 core that references uniqueness (I am using draft
> 10, lines 360-362):
>
> The mechanism by which a SAML system entity ensures that the identifier is
> unique is left to the implementation. In the case that a pseudorandom
> technique is employed, the probability of two randomly chosen identifiers
> being identical MUST be less than 2^-128 and SHOULD be less than 2^-160.
> This requirement MAY be met by encoding a randomly chosen value
> between 128
> and 160 bits in length.
>
> I actually think this text is correct! The key words here are: "randomly
> chosen". I believe the case you identify below is the probability of
> collision when one value is already chosen (i.e., a birthday attack). In
> that case, indeed the probability is approximately 2^-n/2, where
> "n" is the
> number of bits.
>
> So, if this is not the text you are referencing, or, if I am
> mistaken in my
> analysis, please let me know so that I can update the errata accordingly.
>
> Thanks,
> Jahan
>
>
> ----------------
> Jahan Moreh
> Chief Security Architect
> 310.286.3070
>
> > -----Original Message-----
> > From: Scott Cantor [mailto:cantor.2@osu.edu]
> > Sent: Thursday, July 31, 2003 10:21 AM
> > To: SAML
> > Subject: [security-services] Possible 1.1 (and 1.0) errata
> >
> >
> > It's been pointed out during review of the latest Liberty
> > documents that the
> > part in SAML about identifier uniqueness is overstated based on
> > the intent.
> > If the point is to use a SHA1 hash, then the actual collision
> > probability in
> > the spec language should be <= 2^-80 instead of < 2^-160
> >
> > Liberty had the same language and it was copied from SAML, so I
> > figured I'd
> > mention it.
> >
> > -- Scott
> >
> >
> > You may leave a Technical Committee at any time by visiting
> > http://www.oasis-open.org/apps/org/workgroup/security-services/mem
> bers/leave_workgroup.php
>
>
> You may leave a Technical Committee at any time by visiting
> http://www.oasis-open.org/apps/org/workgroup/security-services/mem
bers/leave
_workgroup.php

You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave
_workgroup.php



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]