In one of the U-Prove documents, I remember reading something that compared Subgroups versus ECC and it went something like this (paraphrased):


  • Requires a bigger key to achieve equivalent ECC security

    • Unclear: What aspect of the UProve protocol does this affect?
      When compared to ECC, I'm not sure if this growth is linear with Attribute count in a particular certificate, Disclosed count, or is a static growth added to UPTokens or Proof ?
  • Described as less complex than ECC, and is "new" in the 1.1 release of the SDK.

    • Unclear: are subgroups vetted, well understood and 'safe'? I don't want to implement a solution that hasn't achieved a consensus of trust. I believe the focus here is on the Discreet Logarithm assumption. Better question: Which is "safer"?
  • Run faster than ECC

    • Unclear: Is it faster for Provisioning, Proving or both?
      This is important since an implementation may need many one-use UProve tokens, or one that can be multiple-show. The answer to this (and the degree it affects each) will affect architecture decisions.
    • Unclear: Which protocol can be optimized for parallel computing?
      In my tests, only a single CPU ever had a load on it,.. often reaching 100%. I suspect the C# implementation wasn't optimized for parallelisation in either implementation (ECC/Subgroup)


  • Can someone clarify any of the aspects listed above as unclear? I've been researching the Microsoft, and Credentia website for as much information as I can find..

For your reference, the aspect of the API that controls the creation of the IdP as described above is here: (C# / Java)

    private static IssuerKeyAndParameters CreateIssuer(string UIDP, int numberOfAttributes, GroupType groupType, bool supportDevice, string specification)
       // specify the group type: subgroup (default) or ECC
        isp.GroupConstruction = groupType;

        IssuerSetupParameters isp = new IssuerSetupParameters();
        // pick a unique identifier for the issuer params
        isp.UidP = (UIDP == null ? null : encoding.GetBytes(UIDP));
        // set the number of attributes in the U-Prove tokens
        isp.NumberOfAttributes = numberOfAttributes; // alternatively do this:  isp.E = IssuerSetupParameters.GetDefaultEValues(numberOfAttributes);

        isp.UseRecommendedParameterSet = true;

        // an application profile would define the format of the specification field,
        // we use a dummy value in this sample
        isp.S = (specification == null ? null : encoding.GetBytes(specification));

        return isp.Generate(supportDevice);

Update Here are some performance tests that clearly show how Subgroups greatly outperform ECC based verification

Group Type:Subgroup
                               Attribute Count: 5
                     Time to create 100 Tokens: 00:00:35.7045391
 Time to validate 100 presentations of 1 token: 00:01:44.2874433

Group Type:ECC
                               Attribute Count: 5
                     Time to create 100 Tokens: 00:02:52.5378040
 Time to validate 100 presentations of 1 token: 00:08:22.3521344
  • Subgroups of which supergroup? Subgroups of a finite field are used quite often, but they should be slower than ECC. – CodesInChaos Jun 29 '13 at 8:01
  • Oh they're using BouncyCastle, that explains why their ECC code is so slow. BC seems to be using affine coordinates, doing a modular inversion for each point addition/doubling. – CodesInChaos Jun 29 '13 at 8:35
  • @CodesInChaos My understanding of subgroups is limited and new to U Prove. Any pointers to reading material would be helpful – Christopher Jun 29 '13 at 15:26
  • I don't know what U Prove uses, but there are Schnorr groups which are used in DSA. – CodesInChaos Jun 29 '13 at 15:47
  • Just a note of caution: BouncyCastle's ECC implementation screams timing attack. I don't know if/how to exploit it, but there were some timing attacks against OpenSSL's ECC, those or similar attacks might apply to BouncyCastle as well. – CodesInChaos Jun 29 '13 at 16:41

U-Prove is a technology which is, roughly, a mix of digital certificates and blind signatures. The Prover has a few "attributes" that the Issuer (i.e. the Certification Authority, more or less) asserts to be true. However, when dealing with any given Verifier, the Prover wants to be able to choose what he shows: namely, he wants to show only some of the attributes. Moreover, when the Prover deals with several distinct Verifiers, the Prover does not wish the Verifiers to be able to correlate their inputs and notice that the same Prover was involved in both cases.

In the specification, the cryptographic algorithms which achieve that are described. Namely, there is a finite group in which all participants play. That group is either a subgroup of the integers modulo a prime p, or an elliptic curve. The group has a size q (in the "subgroup" case, q is necessarily a divider of p-1). Each group element can be represented as a sequence of bytes. The group must be such that discrete logarithm is not feasible.

To give some figures: suppose that we want "112-bit security", i.e. something quite strong by today's and tomorrow's standards. This is a level of resistance which cannot be broken unless the attackers musters enough computing capabilities to perform at least 2112 elementary operations, a figure which is way too high to be economically feasible with today's technology. To get this level of security, the group size will have to be at least 224-bit long (q must be no less than 2223). For the elliptic curve, it will be sufficient to have a "224-bit curve" whose elements can be encoded over a sequence of 225 bits (or 224 bits in some cases, depending on the underlying protocol). On the other hand, when working modulo a prime p, there are known shortcuts for discrete logarithm, so we need a much bigger p, up to about 2048 bits (see this site for a lot of data on the subject). An integer modulo a 2048-bit integer p can be represented as a sequence of 2048 bits.

In that sense, when using the "subgroup" model, group elements used in U-Prove tokens are about 9 times longer than what they would have been if the "elliptic curve" model had been used, for the same level of security. Note, though, that the "9" figure depends on the security level (it is not linear).

A U-Prove token itself contains a number of fields, two of which (the public key h, and a part of the signature σ'z) are group elements. Therefore, for the 112-bit security level, a U-Prove token using a "subgroup" ought to be about 455 bytes longer than a U-Prove token of equivalent security but relying on an elliptic curve. Mind the "ought to": this figure is theoretical; I haven't tried. Encoding peculiarities may change that a bit. Also, a U-Prove token includes other fields which may dwarf this difference, to the point of making it irrelevant. This really depends on the usage context.

As for performance, the text you quote is weird, because, usually, elliptic curves are faster (because they work in a much smaller field). In practical situations involving computers or smartphone, computing costs are usually negligible with regards to I/O (network latency and so on), but when smartcards are involved, the difference can be important. If a given implementation of U-Prove is faster with 2048-bit subgroups than with 224-bit elliptic curves, then that implementation is quite sloppy (as @CodesInChaos says in his comments).

On security: Current state of affairs, with regards to the relative resistance of prime subgroups and elliptic curves, has not changed much in the last 20 years. Best known algorithm for discrete logarithms modulo a big prime p is still a variant of the General Number Field Sieve, and there is no known shortcut for discrete logarithms in elliptic curves.

Although computations in the "subgroup" case are slower and need bigger values than elliptic curves, they are also noticeably simpler to implement, in particular when it comes to thwarting side-channel attacks (e.g. timing attacks). Implementing robust cryptographic primitives is hard; don't do it unless you really must. But if you have to do it yourself, then you will prefer the "subgroup" case.

  • Are there any issues with using subgroups with Smartcards? I notice that all the UProve device implementations I've seen use ECC.. and also that MSFT and Gemalto announced joint technology agreement, that I can only assume means they are implementing subgroups into cards. Is this correct? – Christopher Jul 2 '13 at 18:34
  • Smartcards are not very powerful devices. The computational cost can be non-negligible for a smartcard, so smartcard vendor will "naturally" aim for elliptic curves, or include hardware accelerators (special chips for speeding up big arithmetic operations), or both. As for Gemalto supporting subgroup-based U-Prove on smartcards, well, nothing in the press release actually hints at that. – Tom Leek Jul 2 '13 at 18:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.