Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Magnum jumbo #3

Closed
wants to merge 89 commits into from
Closed

Conversation

samueletonon
Copy link
Contributor

hello,
this is a test for a push commit.
In this push commit there are many changes:

  • nsldaps, sha1, rawmd5 and nt have been renamed to opencl_xxx_fmt.c
  • rawmd5 and nt have been improved
  • nsldaps and sha1 have been significantly improved
  • a new ability to detect / set Local Work Size and Keys per Crypt through variable
  • mysql-sha1-opencl has been added

solar and others added 30 commits November 28, 2011 02:24
…e it

printed nonsense on Windows 9x, but those systems are irrelevant now.
(Besides, builds made with recent versions of Cygwin were reported not to work
on Windows 9x anyway.)  Windows NT 4 already provided virtual times under
Cygwin just fine.
binaries (on other platforms), to support OpenMP-enabled builds with Cygwin
(OMPFLAGS is included in LDFLAGS).
faster on P3, P4, Core 2, Core i7, and likely on other CPUs.  (gcc 4.1's BF_X2
code is also faster on most of these CPUs, but slower on P4.  gcc 4.0's code
is slower on many CPUs.)
- With 32-bit x86 builds and at least MMX enabled, the "two hashes at a time"
code for bcrypt is now enabled for GCC 4.2 and newer.  This change is made
based on benchmark results for different builds made with different versions of
GCC on CPUs ranging from Pentium 3 to Core i7.  Previously, this code was only
enabled for x86-64 and/or OpenMP-enabled builds.
- Assorted minor corrections to Cygwin builds were made.
Conflicts:
	src/Makefile
	src/bench.c
	src/params.h
	src/x86-mmx.h
	src/x86-sse.h
… call.

A 32-bit number became insufficient with OpenMP support for some fast hashes,
where a lot of buffering is required for decent performance (one crypt_all()
call processes thousands of candidate passwords, and there may be thousands of
hashes per salt as well).
…n the

traditional one (that is, almost everywhere).  Support OpenMP.
…ecause of

what looks like a FreeBSD headers bug (or at least a limitation).
Reported by Alexey Dokuchaev:
http://www.openwall.com/lists/john-users/2012/01/09/4
…iles?"

(these have been included in all JtR tarballs for years).
Dropped "How do I "unshadow"?" (this was redundant with one of the answers to
"Why doesn't John load my password file?").
Moved "How long should I expect John to run?" up.
- Enhanced the support for DES-based tripcodes by making use of the bitslice
DES implementation and supporting OpenMP parallelization.
- Updated the FAQ.
…odes,

skipping the bits corresponding to the 3rd crypt(3) output character, which is
not included in tripcodes.
DES_bs_crypt_25() call or/and before each cmp_*(), zeroize crypt_out in advance
and then copy just the 58 significant bits into it.
…lds after

testing on 1 million of tripcodes.
…d before)

because the underlying interfaces use ARCH_WORD, so things would break on e.g.
64-bit big-endian even though we're only using the least significant 32 bits.
… when

count is above 0x00100000 since we could end up calling
status_ticks_overflow_safety(), which may involve making a syscall, too often
when there's a large number of hashes loaded for cracking.  For example, if
count->hi is non-zero, we'd end up calling status_ticks_overflow_safety() every
time.  We're also calling status_ticks_overflow_safety() from
crk_process_event(), which should be sufficient.
…uction of

each thread's chunk for DES and MD5, and with only a 3x reduction for BF).
…ller than

ARCH_SIZE bytes.  This sometimes saves a little bit of memory on 64-bit.
Test pointers returned by binary() and salt() for possible misalignment.
Make sure the declared binary_size and salt_size are sufficient to actually
hold the binary ciphertexts and salts.  (We do this by copying the values
returned by binary() and salt() only to the declared sizes.)
Test that binary_hash*(), cmp_*(), and salt_hash() accept pointers with only
the minimum guaranteed alignment.
…H_WORD for

binary ciphertexts.  The latter was wasteful on 64-bit.
…LM hashes

in -jumbo, then re-testing on LM hashes in current main tree code to ensure
there are no major ill effects.
…tation and

corrected it for the case when the bitslice DES implementation computes more
than one DES_bs_vector worth of outputs (this is currently the case when
building with OpenMP).  The use of db->format->params.min_keys_per_crypt was
thus wrong (it took OpenMP parallelization into account, even though that was
irrelevant to relative complexity of the two algorithms).
kholia added a commit that referenced this pull request Jun 6, 2015
kholia added a commit that referenced this pull request Jun 8, 2015
jfoug referenced this pull request in loverszhaokai/JohnTheRipper Sep 28, 2015
@ghost ghost mentioned this pull request Apr 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants