I have a question:
Let’s assume I encrypt string A with string key B, C = AES(B,A) and then I encrypt string B with string key A, D = AES(A,B).
Let’s say using AES algorithm.
If an attacker knows that AES is the algorithm I used and also has C and D, can they figure out strings A and B?
I need to decrypt c and I was given only n, e and c and computing p and q or phi(n) would be close to impossible so what other alternatives do I have? I tried calculating p and q but I made very little progress with the search in the last 24 hours of continuous running the program.
These are the values I was given:
n: 58900433780152059829684181006276669633073820320761216330291745734792546625247
e: 65537
c: 56191946659070299323432594589209132754159316947267240359739328886944131258862
Also, in another challenge only c and n were given and the values were a lot bigger. Do you have any suggestions for that too?
Well, it seems that this question is CTF related, because the patterns of n, e, and c are weak numbers.
You can solve it with RsaCtfTool:
python RsaCtfTool -n 58900433780152059829684181006276669633073820320761216330291745734792546625247 -e 65537 --uncipher 56191946659070299323432594589209132754159316947267240359739328886944131258862
timctf{CENSORED}
https://www.dcode.fr/rsa-cipher
Try this one but it need p and q. So I use the hand calculator to find p and q.
Using Fact(n), ex: Fact(91)= 7x13, so p=7, q=13
Consider two computers A and B. A has uses G and B uses G' where G' != G and of different degrees. Computer A wants to send a data D and it uses CRC for that cause.
The claim says that there couldn't be a scenario where A sends a CRC-message corresponding to data D and computer B will accept it as a valid message. Why is that?
We know that computer A sends D*2^r XOR R (r is the degree of G) and computer B divides by G'. So in other words, why can't G', accidentally, divide D*2^r XOR R?
Obviously it has something to do with the fact that deg(G) != deg(G') but I didn't figure it out.
Thanks!
I am fairly new to the Z80 and machine code, so please don't assume I know anything.
Basically, what I want to know is this: If you load register H with a value (I'll call it y), will HL then be 0xy0? e.g. if H was loaded with 0xAF would HL be 0xAF00?
And would the same be true for loading L with y?
Thanks in advance.
The H and L 8-bit registers can be treated independently. Loading a value in H, will not affect the value in L, and vice versa. The two registers H and L can also be treated as a 16-bit register pair. The following source FIRST STEPS IN MACHINE CODE describes this.
two single register transfers, e.g.
LD H, B
LD L, C
to copy BC into
HL.
and
You can, if you wish, load a register pair directly with a single
instruction, rather than use two instructions. From last time, you
will recall that the H and L, B and C, and D and E registers can be
paired such that they effectively can hold any number between 0 and
65535 (00 to FFFF hex). C, E, and L form the low byte of the pair,
while B, D, and H are the high bytes.
5
0001 -417.031
C 1.04168, -0.05620, -0.07148 1.041682, -0.056200, -0.071481
H 2.15109, -0.05620, -0.07150 2.130894, -0.056202, -0.071496
H 0.67187, 0.17923, -1.09059 0.678598, 0.174941, -1.072044
H 0.67188, 0.70866, 0.64196 0.678613, 0.694746, 0.628980
H 0.67188, -1.05649, 0.23421 0.678614, -1.038285, 0.228641
8
0002 -711.117
C 0.99571, 0.01149, -0.09922 0.995914, 0.011511, -0.099221
C 2.51489, 0.01148, -0.09922 2.514686, 0.011466, -0.099226
H 0.61911, 0.74910, -0.83887 0.597259, 0.729877, -0.819596
H 0.61911, 0.28325, 0.90938 0.597259, 0.276170, 0.883106
H 0.61909, -0.99785, -0.36818 0.597278, -0.971531, -0.361167
H 2.89151, 1.02083, 0.16973 2.913322, 0.994509, 0.162719
H 2.89149, -0.26027, -1.10783 2.913341, -0.253192, -1.081553
H 2.89149, -0.72612, 0.64042 2.913341, -0.706900, 0.621148
These two data points are from chemical database GDB 13. I try to understand what these numbers are representing. I know 5 and 8 are atomic number; 0001 and 0002 are atom id; and -417.031 and 711.117 are atomization energies. However, I don't quite understand what those number below means. However, I am pretty sure they are the geometry representation in 3 dimension space. If that is the geometry representation in 3 dimension space, then why there are 6 numbers in there. How to read those 6 numbers?
I am also trying to use BOB representation to reform the data, is there any ways to do that instead of hard coding? If not, I am using R, is R able to do that ?
Have a look at the original paper in Int. J. Quantum Chem., 2015, 115, 1058-1073 (DOI).
The Extended XYZ format is explained in Fig. 7 of the article.
You are right that the first line denotes the number of atoms k, while the second line consists of an identifier and the energy of atomization for the particular molecule.
The next k lines contain two sets of cartesian coordinates (in Angström). The left block contains the x,y,z coordinates from a force-field calculation (UFF), while the coordinates on the right stem from a DFT calculation.
A common tool to read and convert coordinate files in various formats is Open Babel. Have a look at th accompanying paper in J. Cheminformatics, 2013,3:33 (DOI)
There exist various bindings for Open Babel, and apparently, there is is one for r too. Have a look.
I just ran a quick test on the first entry in the data from the supplement of the paper by Mathias Rupp using Open Babel 2.3.2:
obabel -ixyz c1.xyz -oxyz -O c1a.xyz
Apparently, only the left coordinate block is read in! If you suspect that the coordinates from UFF and DFT calculations differ significantly, you're probably on your own. However, given that the file format is documented, this should not be a major problem.
If you don't mind a remark, the title of your question is somewhat misleading. The data in question is only remotely related to GDB-13. To my knowledge, the GDB files from Jean-Louis Reymond do not contain any coordinates. They are large collections SMILES strings, from which coordinates would have to be generated for each entry.