Factor to large

[jsampson80]

Hello, when I get to the step were I run Python unfactor.py my_encrypted_jpg.vvv and input my factors it says for the last one(94) Factor too large. Is there anything I can do about that? Thank you!

P1: 2 P1: 3 P1: 5 P2: 11 P5: 239027 P12: 352269155477 P16: 6332294919286613 P23: 88057901785428954872993

P94: 2048825042277246591198648663093674187563350153154340323691608669617660568101768930331502958213

[Googulator]

A P94 factor is impossible, as it can't be stored on 256 bits, and the number being factored is known to he two 256-bit numbers multiplied together.

You must have made a mistake when copying the number into your factoring utility.

[Demonslay335]

Make sure if you are factoring one of the keys still in hexidecimal form, you must prefix it with "0x" for msieve or yafu.

Let us know if you need help factoring the number, you may paste it here and we can help.

[jsampson80]

Ok thanks I figured I screwed up somewhere. I ran the AES and Bitcoin last night and the AES was still running when I got up this morning but the Bitcoin was finished. AES: 9B2A14529F5CEF649FD0330D15B4E59A9F60484DB5D044E44F757521850BC8E1DCDF3CB770FEE0DD2B6A7742B99300ED02103027B742BC862110A1765A8B4FC6

BITCOIN: 372AE820BBF2C3475E18F165F46772087EFFC7D378A3A4D10789AE7633EC09C74578993A2A7104EBA577D229F935AF77C647F18E113647C25EF19CC7E4EE3C4C

I got this back from the Bitcoin: recovered 14 nontrivial dependencies p1 factor: 2 p1 factor: 2 p1 factor: 3 p1 factor: 7 p2 factor: 11 p2 factor: 17 p2 factor: 19 p3 factor: 139 p4 factor: 2311 p8 factor: 14278309 prp12 factor: 465056119273 prp15 factor: 250220277466967 prp21 factor: 373463829010805159059 prp22 factor: 1261349708817837740609 prp68 factor: 38505609642285116603442307097561327764453851349351841755789120180499 elapsed time 01:21:09

Just wondering if that looks right? Thank you!!

[Demonslay335]

Yep, looks good. Factored in 5 seconds for me, lol. You got lucky with a simple one. Definitely use the BitCoin one with unfactor-ecdsa.py, you will be able to decrypt all of your data with it for sure.

[jsampson80]

Lol, awesome! I'll give it a go after work. Thank you very much!! Quick question about magic numbers, I see there is list of a few in the readme on this site but is there a site where I can them look up. As I have a lot of pictures in .ORF(Olympus RAW format) Again, Thank you!

[Demonslay335]

If you use unfactor-ecdsa.py, it doesn't require the magic number. It will simply refactor any file with the primes given. When it builds the key, plop that into the known_keys in teslacrack.py and continue; no need for messing with the file types at all that way.

[jsampson80]

Thank you!! I'll let you know how it goes. You guys are awesome!

[jsampson80]

Hey, I finally have time to get around to this just wondering how I enter the Bitcoin

[jsampson80]

Sorry, hit enter. Just wondering how I enter The Bitcoin private key into teslacrack.py known keys. I keep getting an error Here's my key: 38F47CB4BB4B0E2DA4AF771D618E9575520781F17E5785480F51B7955216D71F

[Demonslay335]

What is the error? Follow the syntax of the keys already in the script, it must be in quotes, and have proper commas since it is an array.

[jsampson80]

It just said invalid syntax line 30 }

I figured it out with the tesla decoder and the Bitcoin key though and and am in the process of decrytion now.

[ankostis]

Hi @jsampson80 , I'm trying to make a test-case for bitcoin-keys. Would you mind sharing one or two of your encrypted files containing the above BTC-key? [edit:] and your public btc-address.

[jsampson80]

I'll have to see if I have some unencrypted files leftover but if I do where should I send them, and where would I find my btc-address?

[ankostis]

You may drag n drop them here, if they are not that big and confidential.

I have back-calculated your btc address, so it's ok

[jsampson80]

https://app.box.com/s/tqlfd0pgxdwt44rxxr29qyluyog1rsp9

This is the only one I could find, hope it helps. Let me know if the link does not work.

[ankostis]

Thanks!

[ned64]

Hello,

I have the same issue - my keys seem to have factors that are too large. What am I doing wrong? From two files I get:

File 1: AES: 'D29CE3528881F95365C2758C4215DBB8B6361F889AF0CB0DC31D1BDAF8311337461AF98AA762C6EE595F9F86493BF4EED7914E462EA58281C3EB3B2C3807FE32' BTC: 'ADA7734F0909776CE951CF3AA4C6618E63CA53D7301C57622C455E961FE2C1212ABAAE5C8738D19578406890D791C45A4F94E925176CFF457EF033B29510999C'

File 2: AES: '2188973312D5483615EEE2CDE1209B096D102EBD502699D7E4B226B495ACF4A0E1BF2D66EC90102845AE0A91ECE17E28AB24A6946CC446D1E3C6D9F2E61F9C58' BTC: ''

All three numbers exist on factordb.com, and all of them have a factor which is longer than 2^256 - how is that possible?

[Demonslay335]

Factor the C121 at this link. You must have a copy/paste or conversion to decimal error.

http://factordb.com/index.php?id=1100000000824282917

[Demonslay335]

That is the BC key by the way, so you can use TeslaRecoder to decrypt ALL files once you refactor the key using unfactor-ecdsa.py.

[ned64]

Thanks for the very fast reply! So my mistake was to assume that the big factor C121 is already a prime - I need to msieve -v $NUMBER, then use those with unfactor-ecdsa.py, right?

[Demonslay335]

Yep. The CF for the number itself means it doesn't have all primes listed, so usually the last one is still Composite.

Make sure to use -t (threads) with msieve to utilize your cores to factor faster. If ECM goes to t30 or more without getting another factor, Yafu will be better to run.