sebastien-riou / aes-brute-force Goto Github PK

Using Intel AES-NI and c++ threads to search an AES128 key (well, part of it)

License: Apache License 2.0

Batchfile 0.38% Shell 9.37% C 16.60% C++ 73.64%

aes-brute-force's Introduction

aes-brute-force

Using Intel AES-NI and c++ threads to search AES128 keys. Sometimes side channel attacks recover most key bytes but not all. This project allows to brute force remaining bytes on commodity hardware.

The AES-NI code is a header only library.

Measured performances

On a i7-4770K CPU @ 3.50GHz, a CPU a few years old, 4 bytes takes under a minute, 5 bytes few hours.

daubsi reported testing over 1.2 billion keys per seconds using a machine with 4 Xeon E7-8867 v4 @ 2.40GHz.

Search time greatly varies depending on the most significant unknown byte as the search is done using natural order...

Demo on Windows with Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz

F:\aes-brute-force>build_test.bat

F:\aes-brute-force>c++ -Ofast -std=c++11 -Wall -march=native
 ./test/aes-brute-force.cpp -I ./include -lpthread -o aes-brute-force.exe


F:\aes-brute-force>aes-brute-force.exe
AES128 encryption key brute force search
Usage: aes-brute-force.exe <key_mask> <key_in> <plain> <cipher> [n_threads]

launching test/demo...

aes-brute-force.exe FF0000FF_00FF0000_0000FF00_00000000 007E1500_2800D2A6_ABF700
88_09CF4F3C 3243F6A8_885A308D_313198A2_E0370734 3925841D_02DC09FB_DC118597_196A0
B32

INFO: 8 concurrent threads supported in hardware.

Search parameters:
        n_threads:    8
        key_mask:     FF0000FF_00FF0000_0000FF00_00000000
        key_in:       007E1500_2800D2A6_ABF70088_09CF4F3C
        plain:        3243F6A8_885A308D_313198A2_E0370734
        cipher:       3925841D_02DC09FB_DC118597_196A0B32

        jobs_key_mask:000000FF_00FF0000_0000FF00_00000000

Launching 32 bits search
This can take a couple of minutes on slow computers.

Thread 1 claims to have found the key
        key found:    2B7E1516_28AED2A6_ABF71588_09CF4F3C

Performances:
        1595256342 AES128 operations done in 17.4231s
        10ns per AES128 operation
        91.56 million keys per second
INFO: found the expected key, test passed.

Demo on Linux within Virtual Box / 1CPU (Host being Windows with Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz)

user@user-VirtualBox:~/aes-brute-force$ ./build_test.sh
user@user-VirtualBox:~/aes-brute-force$ ./aes-brute-force
AES128 encryption key brute force search
Usage: ./aes-brute-force <key_mask> <key_in> <plain> <cipher> [n_threads]

launching test/demo...

./aes-brute-force FF0000FF_00FF0000_0000FF00_00000000 007E1500_2800D2A6_ABF70088_09CF4F3C 3243F6A8_885A308D_313198A2_E0370734 3925841D_02DC09FB_DC118597_196A0B32

INFO: 1 concurrent threads supported in hardware.

Search parameters:
	n_threads:    1
	key_mask:     FF0000FF_00FF0000_0000FF00_00000000
	key_in:       007E1500_2800D2A6_ABF70088_09CF4F3C
	plain:        3243F6A8_885A308D_313198A2_E0370734
	cipher:       3925841D_02DC09FB_DC118597_196A0B32

	jobs_key_mask:FF0000FF_00FF0000_0000FF00_00000000

Launching 32 bits search
This can take a couple of minutes on slow computers.

Thread 0 claims to have found the key
	key found:    2B7E1516_28AED2A6_ABF71588_09CF4F3C

Performances:
	363730475 AES128 operations done in 40.3497s
	110ns per AES128 operation
	9.01 million keys per second
INFO: found the expected key, test passed.

aes-brute-force's People

Contributors

Stargazers

Watchers

Forkers

atreff giantdarth xdev-x rob0tsunny philflex2020 logan007 pavlinb jqk6 carrascoii xurz97 xiangchu0 piglord7767

aes-brute-force's Issues

New byte range function segfaults on some systems

aes-brute-force on some systems when using the latest "restrict keybytes" feature:

`
./test_range.sh

INFO: 144 concurrent threads supported in hardware.

Search parameters:
n_threads: 144
key_mask: 000000FF_00000000_FF000000_FF0000FF
key_in: 41424300_45464748_004A4B4C_004E4F00
plain: 3243F6A8_885A308D_313198A2_E0370734
cipher: CB1D0839_594405D8_E9BB8EAE_2483A8CC
byte_min: 0x41
byte_max: 0x5A

            jobs_key_mask:00000000_00000000_FF000000_FF0000FF

./test_range.sh: line 9: 49369 Segmentation fault (core dumped) `

CPU details:

`
lscpu

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 144
On-line CPU(s) list: 0-143
Thread(s) per core: 2
Core(s) per socket: 18
Socket(s): 4
NUMA node(s): 4
Vendor ID: GenuineIntel
CPU family: 6
Model: 79
Model name: Intel(R) Xeon(R) CPU E7-8867 v4 @ 2.40GHz
Stepping: 1
CPU MHz: 2394.082
CPU max MHz: 3300.0000
CPU min MHz: 1200.0000
BogoMIPS: 4788.16
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 46080K
NUMA node0 CPU(s): 0-17,72-89
NUMA node1 CPU(s): 18-35,90-107
NUMA node2 CPU(s): 36-53,108-125
NUMA node3 CPU(s): 54-71,126-143
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti intel_ppin ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a rdseed adx smap intel_pt xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts flush_l1d `

It works without problems on a less powerful home server system:

`lscpu

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 58
Model name: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz
Stepping: 9
CPU MHz: 1752.750
CPU max MHz: 3600.0000
CPU min MHz: 1600.0000
BogoMIPS: 6385.79
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 6144K
NUMA node0 CPU(s): 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm epb ssbd ibrs ibpb stibp kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts flush_l1d
`

Running aes-brute-force w/o test data works without problems:

`./aes-brute-force
AES128 encryption key brute force search
Usage: ./aes-brute-force <key_mask> <key_in> [byte_min] [byte_max] [n_threads]

launching test/demo...

./aes-brute-force FF0000FF_00FF0000_0000FF00_00000000 007E1500_2800D2A6_ABF70088_09CF4F3C 3243F6A8_885A308D_313198A2_E0370734 3925841D_02DC09FB_DC118597_196A0B32

INFO: 144 concurrent threads supported in hardware.

Search parameters:
n_threads: 144
key_mask: FF0000FF_00FF0000_0000FF00_00000000
key_in: 007E1500_2800D2A6_ABF70088_09CF4F3C
plain: 3243F6A8_885A308D_313198A2_E0370734
cipher: 3925841D_02DC09FB_DC118597_196A0B32
byte_min: 0x00
byte_max: 0xFF

            jobs_key_mask:000000FF_00FF0000_0000FF00_00000000

Launching 32 bits search
This can take a couple of minutes on slow computers.

Thread 21 claims to have found the key
key found: 2B7E1516_28AED2A6_ABF71588_09CF4F3C

Performances:
4760275448 AES128 operations done in 7.28767s
1ns per AES128 operation
653.20 million keys per second
INFO: found the expected key, test passed.`

Restrict keyspace

Is there a way to restrict the key space it is going to test? As far as I understand it tests for every key byte all possible combinations from 0x00-0xff. I would like to change this to e.g. only UPPERCASE characters (0x41-0x5A). In my case the key is not derived from the plaintext password, but key==password and I know some characters of it. So the key is 16 bytes in the range of 0x41-0x5a. How to specify this? Thanks!

arbitrary restriction on the set of possible byte values

It would be super-flexible if there was an option where you could actually specify the keybyte values to use. 0x41 - 0x5d is for example the uppercase ASCII range. Maybe you want to do uppercase and lowercase - which cannot be specified continuously. And I don't always have a 144 core machine at hand to just include the bytes in between. Maybe the bytes to use could be specified as a single param like --bytestouse 4142434451889fa0a1a2a3 etc. for 0x41, 0x42, 0x43, 0x44, 0x45, 0x18, 0x89,0xfa,0x0a,0xa1,0xa2,0xa3, etc.

Originally posted by @OevreFlataeker in #2 (comment)

sebastien-riou / aes-brute-force Goto Github PK

aes-brute-force's Introduction

aes-brute-force

Measured performances

Demo on Windows with Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz

Demo on Linux within Virtual Box / 1CPU (Host being Windows with Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz)

aes-brute-force's People

Contributors

Stargazers

Watchers

Forkers

aes-brute-force's Issues

New byte range function segfaults on some systems

Restrict keyspace

arbitrary restriction on the set of possible byte values

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent