-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Closed
Magnum jumbo #3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…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
…"How do I "unshadow"?"
…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.
…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).
…_hash*() return value.
…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).
This was referenced Mar 26, 2015
Closed
This was referenced Apr 27, 2015
Closed
--encoding=[any but ASCII] --list=[format-tests, format-all-details, format-details] with ASan
#1239
Closed
kholia
added a commit
that referenced
this pull request
Jun 6, 2015
kholia
added a commit
that referenced
this pull request
Jun 8, 2015
Closed
98 tasks
jfoug
referenced
this pull request
in loverszhaokai/JohnTheRipper
Sep 28, 2015
This was referenced Dec 7, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
hello,
this is a test for a push commit.
In this push commit there are many changes: