Decrypting strings C and D without knowing the keys - encryption

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?

Related

is there any Cryptographic loop function that returns first input?

I want to use cryptographic function that returns the initial input or something related to it like its hash,
the function should work like Encrypting some data, then Encrypt the output of the data, and encrypt it again another time, and the loop continue to specific number of iterations and finally it can produce the first input after iterating it.
assuming that we can use any different keys or same key if required in encryption and the function can only go in one way it can't be reversible so i can't run this process from the back loop and finally it should return the first input or something related to its first input by checking the hash of it or something like that.
thanks for help
rsa has this property if you only look at the encryption...
this is because of how rsa works:
n = p * q
e * d = 1 mod phi(n)
x = (x^e)^d = x^(e * d) mod n
if you are calculating mod n, all exponents are mod phi(n), hence d is the multiplicative inverse of e (fermat's little theorem)
since that's a cyclic group and e and d are choosen to generate that group, there's your cyclic property
if phi(n) is secret, calculating d from e is seemingly a hard problem (that's what makes it hard to break RSA)
to reverse the cycle you need the inverse exponent.
but here's the catch: you won't have control over the size of the cycle, and by trying to create small cycles, you will end up with weak keys that can potentially be bruteforced to get the inverse element which will break the one way property
and speaking about cycle sizes... with sufficiently sized rsa keys the cycle sizes are probably too large for you... like not-within-your-lifetime large... phi(n) ... with phi being eulers phi function ... n being p * q ... and p and q being primes with like 1200 digits

RSA decryption using only n e and c

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

CRC: false positive under some circumstances

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!

Z80 register pairs

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.

Encryption at two levels (with a twist)

I have a scenario where I need to encrypt a document, then convert it to another format and then decrypt from that particular format converting into the format which would have gotten had we converted the original document without encryption.
In Steps -
Document D, Encryption E, Conversion C
D with E gives ED
ED converted with C gives CED
D converted with C gives CD
CED when decrypted should return CD
Does anyone know any algorithm/software/technology which help me to do this?
Thanks for the help,
Regards
In terms of encryption, this would only be possible if your encryption E was a stream cypher, and the conversion C was an exact byte to byte translation. Any change to the number of bytes (for example, different end-of-line codes) would render it impossible.
In symbolic terms:
D XOR E => ED (encryption)
ED XOR C => CED (conversion ED -> CED)
D XOR C => CD (conversion D -> CD)
CED XOR E => CD (decryption)
Much simpler to separate encryption and conversion. Only convert a decrypted version of the document.

Resources