Im trying to find out what kind of hash encryption this is in javascipt:
function L(j) {
var h = a.pbkey,
g = a.rndnb;
if (typeof f != "undefined") {
var e = f.PBK(h),
d = f.STBUNC(j),
i = f.STBA(g),
c = f.ENC(d, e, i),
b = f.BAT64(c);
return b
} else return ""
}
It hash a phonenumber.Ex: +79645531974
pbkey:'e=010001;m=d06889ab9ea3c9ce9d2e92559d6b2f043ef873f0cc9f858745bc6784d1d9a98f8d354e061d25fad9c3a741c57626d0d65de01eb03584a5af1f579b9f9834a60b628756ad636ec1d3129e87e0c7274670d9ca615f12fe3424e9da362f7f8cce8dfe61d79f5ec68dffe1f3ddcf5e20e1bf07349ee6c747a59b09d6420d131899f93dfaeacd76d6a684cda8ac99e7f87e17507235a2b59b84f56d8a3d4ecdd8259b3c7d892758d69a48930b591e66cc6d88d20a3de9360be30c8a94084a2753c92e0cfd1c94868c90109cd176855bba96cd3e73f34442ddfd256da7f1d1e48fbf265ad2f2caeebe4990ca5638b90b6c3fafa8c015a09947e3f03defc51e231a2f2d'
rndnb:'7fc1cdfea47d0057bbb33176ce73a376f9319d4e221d84807d74ff2f859b510b9fd132e577ed207d96b1d11e57500bff93efe97842248bcbe39527592797b7e3a821110ae61c3da67c2773bcb634c53357fb230ef95297d20c37d256aa8bd75bea315f2d
Result: 4LW/+zyiBBgDExOLPLafO9T/GG3guycSMK3uz16qFcXWgvo1KAF8VrbGrxAE91Mvk6qUDkX8c9ha7urDB41XDAhciBbj2VzE48WXjB/A6gI6n7qcTwkNTPT0Qly1EFRtTF44xTbPEld/OviYhD2OolumbtL42wtnyw1oh4/2v2SyAqARdGJizRhd1UFpWW+OUIcF3eyhKS1R+TDorsOoM/bJQzR6CTSyLysfPJL8ldjG0Ujevac7dT+WvaXFmP3qlsReMP/FSLjs7xixCAA/VrxIRUragoIOf2cptilop5zJNY26DO/iEhUUU7n8ANayrqthplS3v624XR24iM22bg==
The code suggests that it uses 2048 bit RSA encryption (with public exponent 65537) and a randomized padding scheme.
But with only this code it is impossible to solve the whole thing. We need to know what the PBK(), STBUNC(), STBA(), ENC(), BAT64() functions do, otherwise we cannot definitively say anything about what is done here.
However, the input parameters give some suggestions. The pbkey parameter suggests that the encryption is "public-key" based and uses an exponent e = 65537 (a commonly used RSA public exponent). Then it's an easy guess that m stands for "modulus". We could be dealing with either RSA or some logarithm-group crypto (e.g. ElGamal). To get more information we could check if this modulus m is a prime number, turns out it's not. So logarithm-group crypto is off the table and so we are probably dealing with RSA. Notice how the modulus and the output are each 2048 bits, so this checks out.
But we're not done. We also have the rndnb value, which probably means "random number". This suggests that the encryption is not textbook RSA (thank god), but uses some kind of randomization. Possible it uses some kind of standard padding scheme like OAEP.
To get more details we would really need to get the bodies of the functions that are use.
Related
Given a password P and hash H, the function bcrypt.compare(P, H) tells you whether or not H is a bcrypt hash of P.
Question: How does bcrypt.compare do the above? It's mysterious to me since P may be associated with many different hashes, and bcrypt itself doesn't seem to have any "memory" of the hashes it creates for P.
(Bonus question: Am I right to assume that the above implies that each bcrypt hash is associated with exactly one password? Or am I wrong -- may a hash be associated with many passwords?)
Hashing:
string BCryptHashPassword(password)
{
Byte[] salt = GenerateSomeSalt();
return DoTheHash(password, salt);
}
Verifying:
Boolean BCryptVerifyPassword(password, expectedHash)
{
Byte[] salt = ExtractSaltFromExpectedHash(expectedHash);
String actualHash = DoTheHash(password, salt);
return (actualHash == expectedHash);
}
It hashes the password again with the original salt, and compares them.
}
BCrypt does not only save the hash in H it also saves among other things the salt used to create the hash (here a full explanation).
Match takes the raw password and the expected hash to match a password, so it simply extracts the salt from the expected hash and reapplies it to the raw password.
Suppose you have an existing hash g84t5tw73y487tb38wo4bq8o34q384o7nfw3q434hqa which was created from the original string dont downvote my stupid question
Now I timestamp this hash like this (in JS/pseudo-code):
var hash = 'g84t5tw73y487tb38wo4bq8o34q384o7nfw3q434hqa';
var today= new Date(); // 2017-10-19
var timestamped = hash + today;
var new_hash = SHA256(timestamped);
// new_hash is 34t346tf3847tr8qrot3r8q248rtbrq4brtqti4t
If I wanted to verify my original string I can do:
var verified = goodHash('dont downvote my stupid question',hash); // true
If I wanted to verify the timestamped version I can do:
var original_hash = 'g84t5tw73y487tb38wo4bq8o34q384o7nfw3q434hqa';
var today = '2017-10-19';
var verified = goodHash(original_hash+today, timestamped_hash); // true
But if I tried to verify the original string against the timestamp, I CANT do:
var today = '2017-10-19';
var verified = goodHash('dont downvote my stupid question'+today, timestamped_hash); // FALSE
Now suppose this original string is hashed and timestamped over and over again for n iterations.
I would only ever be able to verify the n-1th timestamp, provided I have the n-1th hash.
But what if I have the original string dont downvote my stupid question and want to verify any ith timestamp, where 0 < i < n.
Basically, I want to verify whether a string that only I should have knowledge of, has been timestamped with a given date, regardless of how many times it may have been timestamped and without increasing the length of the string (too much - although any increase in length would approach infinity as n grows).
Is this even possible? Can a hash even contain all this information?
Let's look at the mathematics involved here:
First, you have a input string s and a sequence t of timestamps. I will use t[i] to denote the ith timestamp. Your repeated hashing is a recurrence relation:
f(i) = hash(f(t[i-1]) + t[i])
Where + denotes string concatenation. Now we want to determine if there is a closed formula F(x) which will calculate the ith hash with less time-complexity than evaluating the recurrence relation f(i).
One way to accomplish this is to find a string x(i) with the same hash as f(t[i-1]) + t[i]. For a good hashing algorithm, these collisions are exceedingly rare. My gut instinct is that finding such a string (other than f(t[i-1]) + t[i] itself) is more difficult than simply calculating directly from the recurrence relation.
This is a RSA private key :
<BitStrength>4944</BitStrength>
<RSAKeyValue>
<Modulus>vqZ07gIBoLEzJZHhNYj3WSt9F5iw/Klr/hb22Q8YT5NivYS8UpuzteNHpE7u0pk4Izcto4fqtqPHFpXxzhpswtCwOO7czabK/8B+im6T6aRHSSbZXB59NPxj883BS04F1/zziwPj84Ez+/t1ckrK8O/Gbo8DOr4UPQ3CDoDw4gAQpNe4H48zfGV42WIOQjm00DHOhgpFpZaYapXjDz3KfbdY+p4y1R0Yt4eNViRmvQ2jBPIeXVZACC3Ef3J0TCTWne+1Y4gCfMl0z+4hkE1XZpPiDxt2BR46GYU+NwsrI82pIJ6Bigj51jYpgPE4uQBmjYylY/HTJw4b6N45MuljWFuaxOrDHaHdskhSGUS+fAzp5KXh1xsRdzXysv6uliPU3BmgNsM0Av5Gm4EnVoeqjeC/0G3dLoIJi//IqBCNGOfV8sSo/Y6JNGZoAlE6KT101Q89ClrJyHVoZCbU3qVg9F6tPCorn9+UH9rEKQbABpMMjBM3H2MFuiUlvDWlatP+VH1WugKInlP3b20cINGs+Z5obUYcnAiZ8Dj5WN+OVOZH2nqG3X/Hl+V/87kAVhl1lb1gkDzl53aJ+CgmKJ8GRNdxhtV0xmfewrGxhVdWR3qszY05O1GH914tD0viDXgGDIq6ZyHm78XKQQ6eztdfxT/pNi4Dmtd49vyjSjseEa8uMn/KjvePIBJ02pweSo7tkROptAENE+MWSANdH89NU06tOC+bQ57TaVD2AKvlo8nZudshMrBMXRsUYTsy0kRnFvjPw4U2EUz3rfNLabela1OS1gR8QvPaFBf+mxxJgk002xPgSAdhVRiv</Modulus>
<Exponent>AQAB</Exponent>
<P>8RUZbaB91ve478Jam2QjOWooTrvtaOzoe6hygPA8E6GlEqwryGg2180lUUoM+RdFTgmKvxaLyV7Xg4RZHD0vWYmE4VT/ChulT52qn8IPgIV1O+F67EVh4ovVCx/vXEiDCLpzWRgyMr8VazsM71xmLi8N5+3esFNcdoFk7a+7odVC5xIAK8N/BiXu+PVYeai4begJTvXtK1bFFr7TQCmC6JUp84/dFCoNIyMHjVFYuz2Td8D3quxjPRaj+fnjYtce92JD0v5rkfmYTSFt2EbZKkdMJpS7MeDmFErOUDSYVOdu7CbmlVbXcD6QbSC2RbX/fbyTWwyAti3JSJ+WzUbrnp9olXEcldMt7Z8okT2Y9apxmKNYibq0XN+JPhdBlk1EffhRiCGHfFAsNME85dvRI0naJMxD</P>
<Q>ynJ6nUraqvWP178eFFbrY//r274r59ckV/4/TFd/vlxPjLR4XpRgM16o/rrIyjDqko5MCm4f0LYZoNfe/6/Xz1WsbfuFCcp+SdFrVFDjE4rzszys25/fum4TcsSbmsQflNY108QD0Mf+6xBsuVlWh8WWXKim0aplVF6tEiz3bMEWWjTM5Wuv65hEO9V6q+BNJ+j3VqZdVBPKKqnyxxK84zFXec8JqGqYo2qxFEahunagv0hm5sCLerv3GcBAy719q43eecwHfIEgNuAFoMLr4R/IFMLPy31CQHMalFRazfu4CZoIwDkDVZHfACHDoLR+91LbMG/UZhRnv0YZ9+fFajINxTPkgIvLwaf624yZ2DOF8h+Aor5evHZ00/iD6AP0kogjd0JlXTvVVL2R8VeGowfkHnEl</Q>
<DP>oTHmarKg8Zd5hHaDdtsh4kXk5aAqQboGSIh851G6GbY/VZjhPYLRCMIWbaABxJuWr3MZ3mMI3IAZwcpAeu0+N7QHsVLPpMaPZgiaCXAMRXb2yC8frdNGe9/bdzDHLwEc/D0O20eeaOfzPluhbnptp/u2ZJlcCLH0ZRhnj7Ws06xwq2gRzTFOQaIjgzspCU+S4YoAj1dIWW4PIgI95ezbpv/1qPFMdSsY1aGabxcxKSEm9S+Fajfcsv/sbDx1maUVA3wktXOAIX6uIwRzGeVlVyuM808HS3aA4JiUEnTYVgzY0fXAv6HtMxPiJdV1im8CgeQQ8xQNC8LZj0GF54PAD7Oujh2va05kqzl8OoDhQYHRqqmtjYnVBzQ/49BQ/lpzrXbXrRoeKTTCGhQKz/aGg/3hajFZ</DP>
<DQ>TOlFD/DaNkzoguyGvu9uqiUWM/uBrqiblBpxbc1oKKflSO1fNX9lNN7nkS7hDX+b/mW1GdlQmPg1sFeSzsy9TnWb9oSxvFCDvgOjpPq96jTF9Pg+K4oHc0pSdS2geCG+Zcsj0/oKAQ2aGS+6PohkSVyVjUo9ZjY4HN+DHP6cWWLZ3RdmKFrLENReR+UIn7etWFY3cWHu3vxNt/us0liaDi42r34qiyNELgFgmPVkh/R9iW42OcA4vT4f2Fajx0OMNNrHBLqwtWpRFMfzG2oyNureFpUUYJiLzPRtyqBphwv0lSFB5dVDIQU0FVa+fZVVDx0ZTMOPi+CAsbguMXKKG5g8hwj57KQvmrj4ouQ9plecsamqMynjz/Go3MbzRfgKuIikALDm1Y7fszv58BhyfAmJbs9J</DQ>
<InverseQ>3awPjKSwbmVsn+Ip7nwwSRgJHJhHBqr/KmT7NBv9cOAFXEaz9v7VmhSLU3GZcfHi9J0gTa/2POCd5X3IT5bEtf42jDgfP39vGDqc8liWOZG2Ha7Y/TteIO9REAIy7tTPdWWG0TyBVQah4eC0A9KS9GDR1cLL0wdky38ppNwZT3V1kzgBoow1Agea44rM+tgUIZtrPxtHHBNFgX2Mkbn3CZKg1Qpe98GjIGEkZhwMM3RfYo0uW732t908gDNBaMY5S5+ixr3XZfph9wJZiq1JUwMhMPa8gGTLiRNm6rDlNimgaAv3iBnGCZhSdX11bbj5qQrM17wDqyOyk44ywt1T9SW9K6Tode57pUoxVB9XkOLHCnx6of371xx5bhZ4l9NIbdLldfj1CI4bSOMqN/r7UZ96upoJ</InverseQ>
<D>VieCz8u4UJXDN0clLrwmivVMIk2uLX+ifcCC7LQVmGBSTrKdJ/eUzq1Wwrmo0yLKa5+T0EKrnr2ESoCYNTtbyu3jtNa8kXK+abTjekteLEdAr54Ou8JLcpZb1OE2aIFpwqFcrYWkjXXluAl6mZuS+i5gzbVzECi1nKGLAGLkeDzvSI7zdc+QxLZWVmYpa2QIgc0ANzKNJrdXSVNSuKCD0Sv52ceD0SrE8KshA7yPcP+om6OOdT900D1efvmJ9J7xHY4lukTMWvfvAcfrAvrwdDp//bO7MbTnLIE6DEXPyO43b7Yxc996h4MSXmKj73Zu4aidVP0DHrMRibpivs8ZReSfnD06zzlGpjpoX2Lhcc2kJN+Rn1NsISMP+jN9Ufv/RTePXy/3YSLnZX6H+GJ2gIcAJ4B9mwfz8dD6nUFyrhZELvc3/Bp9iW5wYWwbAIKQwAM4MfBBo77ur3VXWymlSwAOj2IQEfCpb0qY7n/3reJ5PfUD17LbWyuboiPL1oRzPp7VgxBXoSYAIQUTimEHOaJUogh3SLeK5b4Vx4ukFZp/c54qfJQz8oHOS3cCXIgiqKhPwDczeCY6h2Ya0YHn32jUacPQu3RyC1KQq+zEQ8nzL8uH7RA2dEYX0Wlco+9d7OamNsQL78+2GhtbKAvPlymMUFLSZVT1pRPpGBdpzQylRQpAk6PG5XZSGNjXPa6nHhHRTuLkCtoEH6xzS5gRTtRUnK8mxXGnc1eTHaVnKMuCdo82YLWCoLobHclHSLiKy20lIR3i84mXH4vLxwdaSMyLDwbDZxkepKx7Ga3J2HXtQ/NDvNoIRxmB</D>
</RSAKeyValue>
It contains couple of elements (Modules, Exponent, P, E, DP, DQ, InverseQ, D)
I read somewhere that the main element of a RSA private key is D.
But I want to know which parts of these elements should be secret and which parts can be publicly shared ? (Means there's no security problem if it be shared)
Thanks
From Wikipedia:
The public key consists of the modulus n and the public (or encryption) exponent e. The private key consists of the modulus n and the private (or decryption) exponent d, which must be kept secret. p, q, and φ(n) must also be kept secret because they can be used to calculate d.
This means that that you are correct. D is the most important part, but because 'd' can be found from other information (p,DP,DQ, InverseQ) they too should also be kept secret. The modulus and exponent form the public key.
source: http://en.wikipedia.org/wiki/RSA_(cryptosystem)
What's the algorithm for creating hash (sha-1 or MD5) of an RSA public key? Is there a standard way to do this? Hash just the modulus, string addition of both and then take a hash? Is SHA-1 or MD5 usually used?
I want to use it to ensure that I got the right key (have the sender send a hash, and I calculate it myself), and log said hash so I always know which exact key I used when I encrypt the payload.
Based on the OpenSSH source code, the way that a fingerprint is generated for RSA keys is to convert n and e from the public key to big-endian binary data, concatenate the data and then hash that data with the given hash function.
Portions of the OpenSSH source code follows. The comments were added to clarify what is happening.
// from key_fingerprint_raw() in key.c
switch (k->type) {
case KEY_RSA1:
// figure out how long n and e will be in binary form
nlen = BN_num_bytes(k->rsa->n);
elen = BN_num_bytes(k->rsa->e);
len = nlen + elen;
// allocate space for n and e and copy the binary data into blob
blob = xmalloc(len);
BN_bn2bin(k->rsa->n, blob);
BN_bn2bin(k->rsa->e, blob + nlen);
...
// pick a digest to use
switch (dgst_type) {
case SSH_FP_MD5:
md = EVP_md5();
break;
case SSH_FP_SHA1:
md = EVP_sha1();
break;
...
// hash the data in blob (n and e)
EVP_DigestInit(&ctx, md);
EVP_DigestUpdate(&ctx, blob, len);
EVP_DigestFinal(&ctx, retval, dgst_raw_length);
From the BN_bn2bin manual page:
BN_bn2bin(a, to) converts the absolute value of a into big-endian form and stores it at to. to must point to BN_num_bytes(a) bytes of memory.
Question: Is there an easy way (library function) to perform a bitwise AND or OR on numbers larger than 32-bit in ActionScript?
From the docs:
"Bitwise operators internally manipulate floating-point numbers to change them into 32-bit integers. The exact operation performed depends on the operator, but all bitwise operations evaluate each binary digit (bit) of the 32-bit integer individually to compute a new value."
Bummer...
I can't use the & or | ops - does AS expose a library function to do this for Numbers?
Specifics: I'm porting a bunch of java to flex and the java maintains a bunch of 'long' masks. I know that I can split the Java masks into two ints on the flex side. Since all of my mask manip is localized this won't be too painful. However, I'd like to keep the port as 1-1 as possible.
Any suggestions?
Thanks!
I think your most straightforward option is to break the masks, and if possible the data being masked, into two pieces. You're butting up against a feature gap, so no point in being tricky if you can help it. And if you don't need real BigNum support, best not to even consider it.
If you don't mind porting some Javascript, Leemon Baird has written a public-domain Javascript library for handling big integers here:
http://www.leemon.com/crypto/BigInt.html
You won't be able to explicitly use the & and | operators, but you should be able to augment the existing code with bitwiseAnd and bitwiseOr methods.
`
public class NumberUtils
{
public static const MSB_CONV : Number = Math.pow(2, 32);
public static function bitwiseAND(num1 : Number, num2 : Number) : Number {
var msb1 : int = num1 / MSB_CONV;
var msb2 : int = num2 / MSB_CONV;
return (msb1 & msb2) * MSB_CONV + (num1 & num2);
}
..OR..shiftRight..
}
`
According to http://livedocs.adobe.com/flex/3/html/help.html?content=03_Language_and_Syntax_11.html, there are no 64-bit integers (signed or unsigned)...only 32-bit.
The Number type, as you mentioned above, has a 53-bit mantissa, which is too short for you.
I searched for a BigNum FLEX implementation, but couldn't find one.
I'm guessing that you will have to simulate this with either an array of ints or a class with a high and low int.
Good Luck,
Randy Stegbauer
public function readInt64():Number
{
var highInt:uint = bytes.readUnsignedInt();
var lowerInt:uint = bytes.readUnsignedInt();
return highInt * Math.pow(2,32) + lowerInt;
}
public function writeInt64(value:Number):void
{
this.writeUnsignedInt(int(value / 0xffffffff));
this.writeUnsignedInt(int(value));
}