I am attempting to create the properly DER encoded ECC parameters for the custom Microsoft P160 PlayReady curve to feed into a HSM. I have found a few sources that specify the definition of the P160 curve since it is non-standard and custom. Below is a link to one source. In particular, the PlayReady curve values are discussed in Section 6.4.2 of the book Elementary Number Theory,A Computational Approach by William Stein.
Below is an exert from another source concerning the P160 PlayReady curve parameters.
For ECC, Microsoft is using an elliptic curve over Zp, where p is a
160 bit prime number (given below). The curve consists of the points
that lie on the curve y^2=x^3+ax+b, where the operations are done over
the field Zp and a and b are coefficients that are given below.
All values are represented as packed binary values: in other words, a
single value over Zp is encoded simply as 20 bytes, stored in little
endian order. A point on the elliptic curve is therefore a 40 byte
block, which consists of two 20 byte little endian values (the x
coordinate followed by the y coordinate). Here are the parameters for
the elliptic curve used in MS-DRM:
p (modulus): 89abcdef012345672718281831415926141424f7
coefficient a: 37a5abccd277bce87632ff3d4780c009ebe41497
coefficient b: 0dd8dabf725e2f3228e85f1ad78fdedf9328239e
generator x: 8723947fd6a3a1e53510c07dba38daf0109fa120
*generator y: 445744911075522d8c3c5856d4ed7acda379936f
Order of curve: 89abcdef012345672716b26eec14904428c2a675
These constants are fixed, and used by all parties in the MS-DRM
system. The "nerd appeal" of the modulus is high when you see this
number in hexadecimal: it includes counting in the hexadecimal, as
well as the digits of fundamental constants e, pi, and sqrt(2).
Based on this information I have created the following hex-encoding of the DER encoded curve parameters for the P160 curve using BouncyCastle as my base ASN.1 library. Note that no seed value is specified in these curve parameters.
308195020101302006072a8648ce3d010102150089abcdef012345672718281831415926141424f7302c041437a5abccd277bce87632ff3d4780c009ebe4149704140dd8dabf725e2f3228e85f1ad78fdedf9328239e0429048723947fd6a3a1e53510c07dba38daf0109fa120445744911075522d8c3c5856d4ed7acda379936f02150089abcdef012345672716b26eec14904428c2a675
Although mathematically these curve parameters are accepted by the HSM and OpenSSL, the P160 curve points produced are not acceptable to PlayReady. I am able to use the same process to produce valid P256 curve points that are acceptable to PlayReady so I do no believe my methods are flawed. Does anyone have any experience with the PlayReady P160 curve parameters?
After researching with Microsoft the solution was found. Apparently one must byte swap the public key x/y points, and the private key to get the PlayReady tool kit to accept the EC key pair only for the P160 curve. This odd byte swapping was not required for the P256 EC key pair.
Related
To all homomorphic encryption experts out there:
I'm using the PALISADE library:
int plaintextModulus = 65537;
float sigma = 3.2;
SecurityLevel securityLevel = HEStd_128_classic;
uint32_t depth = 2;
//Instantiate the crypto context
CryptoContext<DCRTPoly> cc = CryptoContextFactory<DCRTPoly>::genCryptoContextBFVrns(
plaintextModulus, securityLevel, sigma, 0, depth, 0, OPTIMIZED);
could you please explain (all) the parameters especially intrested in ptm, depth and sigma.
Secondly I am trying to make a Packed Plaintext with the cc above.
cc->MakePackedPlaintext(array);
What is the maximum size of the array? On my local machine (8GB RAM) when the array is larger than ~8000 int64 I get an free(): invalid next size (normal) error
Thank you for asking the question.
Plaintext modulus t (denoted as t here) is a critical parameter for BFV as all operations are performed mod t. In other words, when you choose t, you have to make sure that all computations do not wrap around, i.e., do not exceed t. Otherwise you will get an incorrect answer unless your goal is to compute something mod t.
sigma is the distribution parameter (used for the underlying Learning with Errors problem). You can just set to 3.2. No need to change it.
Depth is the multiplicative depth of the circuit you are trying to compute. It has nothing to with the size of vectors. Basically, if you have AxBxCxD, you have a depth 3 with a naive approach. BFV also supports more efficient binary tree evaluation, i.e., (AxB)x(CxD) - this option will reduce the depth to 2.
BFV is a scheme that supports packing. By default, the size of packed ciphertext is equal to the ring dimension (something like 8192 for the example you mentioned). This means you can pack up to 8192 integers in your case. To support larger arrays/vectors, you would need to break them into batches of 8192 each and encrypt each one separately.
Regarding your application, the CKKS scheme would probably be a much better option (I will respond on the application in more detail in the other thread).
I have some experience with the SEAL library which also uses the BFV encryption scheme. The BFV scheme uses modular arithmetic and is able to encrypt integers (not real numbers).
For the parameters you're asking about:
The Plaintext Modulus is an upper bound for the input integers. If this parameter is too low, it might cause your integers to overflow (depending on how large they are of course)
The Sigma is the distribution parameter for Gaussian noise generation
The Depth is the circuit depth which is the maximum number of multiplications on a path
Also for the Packed Plaintext, you should use vectors not arrays. Maybe that will fix your problem. If not, try lowering the size and make several vectors if necessary.
You can determine the ring dimension (generated by the crypto context based on your parameter settings) by using cc->GetRingDimension() as shown in line 113 of https://gitlab.com/palisade/palisade-development/blob/master/src/pke/examples/simple-real-numbers.cpp
I am working on implementing Galios Field Multiplier on FPGA. I want to implement the multiplier which can multiply for degree 163, 253, 288, 409 and 571. I have found an algorithm to implement multiplier but for testing, I need irreducible polynomial for the given degree.
The question is how to find the irreducible polynomial of the given degree. Also is there any way I can generate expected results to check if the implemented logic is correct. Like any online galios field calculator available.
I tried to search on the internet for a calculator but they are based on predefined irreducible polynomial.
There is a technical report from HP Table of Low-Weight Binary
Irreducible Polynomias. Usually, the low-weight is preferable in Cryptography.
Also, you may look at this Finding irreducible polynomials over GF(2) with the fewest terms from math.SE to implement yourself.
You can use Maple, Mathematica, and sageMath to check your results.
The below SageMath code provides all binary irreducible polynomials for a given degree.
degree=4
R = GF(2)['x']
for p in R.polynomials(degree):
if p.is_irreducible():
print(p)
I have implemented the Serial Pollard Rho Algorithm for solving Elliptic curve discrete log problem . Now I am try to parallelize it using the Parallel Pollard Rho Algorithm.
so I just need some help to understand what kind property I can use for selecting distinguished points for collision detection. It would be a great help if some examples can be suggested also.
You could use any property. The thing to get right is the probability for some point to be a distinguished point. For example if we want one distinguished* point per 2^32 points, we could define a distinguished point as a point which has all last x 32 bits 0.
For example in Sage with point P:
>>> P.xy()[0].lift() & 0xffffffff == 0
True/False
In the normal case, this will do, but I admit that this is not really ideal when you are calculating elliptic curve arithmetic in a projective or Jacobian coordinate system, because you will have to do an inversion for every distinguished-point-test.
I`m trying to implement ECDSA in the curve secp256k1 in Google Go.
Secp256k1 is defined by the SECG standard (SEC 2, part 2, Recommended Elliptic Curve Domain Parameters over 𝔽p, page 15) in terms of parameters p, a, b, G compressed, G uncompressed, n and h.
In Go's crypto library, the curves are defined by parameters P, N, B, Gx, Gy and BitSize. How do I convert parameters given by SECG into the ones needed by Go?
In the elliptic package of Go,
A Curve represents a short-form Weierstrass curve with a=-3.
So, we have curves of the form y² = x³ - 3·x + B (where both x and y take values in 𝔽P). P and B thus are the parameters to identify a curve, the others are only necessary for the operations on the curve elements which will be used for cryptography.
The SECG standard SEC 2 defines the secp256k1 curve as y² = x³ + a·x + b with a = 0, i.e. effectively y² = x³ + b.
These curves are not the same, independent of which b and B are selected here.
Your conversion is not possible with the elliptic package's Curve class, as it only supports some special class of curves (these with a = -3), while SEC 2 recommends curves from other classes (a = 0 for the ...k1 curves).
On the other hand, the curves with ...r1 in the name seem to have a = -3. And actually, secp256r1 seems to be the same curve which is available in elliptic as p256(). (I didn't prove this, but at least some the hex digits of the uncompressed form of the base point in SEC 2 are the coordinates of the base point in elliptic.)
I followed How to calculate the inverse key matrix in Hill Cipher algorithm? for the answer but couldn't get how to calculate 'x' in the problem given in the post using extended GCD algorithm
have a look at this
(the question there is about RSA, but what you are looking for is the extended euclidean algorithm - EEA)