just wondering, is it possible to write bitslice implementation for oracle hashes that use (new hash) sha-1 and (older hash) des in cbc mode? if not, why not? thanks -- -- To unsubscribe, e-mail john-users-unsubscribe@... and reply to the automated confirmation request that will be sent to you.
Hi everybody I wonder if there is a compiled binary version that works with NT hashes from passwords longer than 8 chars (8-11 at least) or what changes I need to make to the source code and compile on cygwin. Appreciate any help Thanks in advance Javier J. Martinez Porter Keadle Moore, LLP 235 Peachtree Street, NE Suite 1800 Atlanta, GA 30303. Ph: 404-420-5613 Cell Ph: 404-808-2114 Fx: 404-588-4222 NOTICE: This communication may contain privileged or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this communication in error, and delete the copy you received. Thank you. -- -- To unsubscribe, e-mail john-users-unsubscribe@... and reply to the automated confirmation request that will be sent to you.(Continue reading)
As part of a system audit, I am being asked to audit application admin password. I know it is 12 characters and MD5. I am trying to use John (win32mmx 1.7 multi-patch) with option -i. I have changed the MaxLen to 12. When I run john -i passwordfile (one user's password) I get a message MaxLen = 12 exceeds the compile time limit of 8. Can john's options be set to try and crack a MD5 password larger then 8 characters? -- -- To unsubscribe, e-mail john-users-unsubscribe@... and reply to the automated confirmation request that will be sent to you.
Hi, The attached patch implements the *new* PASSWORD() hash cracker for MySQL versions 4.1 and newer. I've tested it with linux-x86-64, linux-x86-64-32-sse2 and linux-x86-64-32-mmx and it seems to work for me, though I can give no warranties for the MMX/SSE-accelerated versions because the shammx assembly code is totally undocumented. The SSE2 version performs around 11k c/s on my 1.8GHz Core 2 laptop, and 7k c/s on Athlon 64 3000+. If this is not enough for you, the mysqlsha1_set_key routine (inherited from rawSHA1) can really use some improvements. :) If you want to try the cracker, use the _attached_ patch. The following diff lists the changes between rawSHA1 and mysqlSHA1, for anyone who's interested. Note that I use different indentation than the original author so this diff will look awkward. Regards, Marti Raudsepp % diff -puw rawSHA1_fmt.c mysqlSHA1_fmt.c --- rawSHA1_fmt.c 2007-11-03 13:33:46.000000000 +0200 +++ mysqlSHA1_fmt.c 2007-11-10 16:25:12.000000000 +0200 <at> <at> -1,10 +1,24 <at> <at> +// vim: set ts=8 sw=4 et : /*(Continue reading)
Marti, On Sat, Nov 10, 2007 at 04:37:24PM +0200, Marti Raudsepp wrote: > The attached patch implements the *new* PASSWORD() hash cracker for > MySQL versions 4.1 and newer. Thank you for the contribution. I or Erik will consider it for the next revision of the jumbo patch. (Unfortunately, I can't put this patch out on the website on its own as it uses SHA-1 code from the jumbo patch.) -- Alexander Peslyak <solar at openwall.com> GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15 http://www.openwall.com - bringing security into open computing environments -- -- To unsubscribe, e-mail john-users-unsubscribe@... and reply to the automated confirmation request that will be sent to you.
On Fri, Nov 09, 2007 at 01:53:58PM +0000, lerdahl@... wrote: > As part of a system audit, I am being asked to audit application admin password. I know it is 12 characters and MD5. "MD5" as in "FreeBSD-style MD5-based crypt(3)"? If so, you're out of luck cracking that password, unless it is totally trivial (e.g., a dictionary word). > I am trying to use John (win32mmx 1.7 multi-patch) with option -i. You're out of luck cracking an MD5-based crypt(3) password that is 12 characters long with "incremental" mode, even if there were no compile time length limitation for that mode. > I have changed the MaxLen to 12. When I run john -i passwordfile (one user's password) I get a message MaxLen = 12 exceeds the compile time limit of 8. Indeed, but that's not the primary reason why that would not work well. > Can john's options be set to try and crack a MD5 password larger then 8 characters? Yes. There are cracking modes other than "incremental". Those do not have the compile-time length limitation and they actually have a chance of cracking your long password. Use the "single crack" mode, then a wordlist with word mangling rules (or two wordlists: first a tiny one, then a larger one), then maybe try the "keyboard" external mode (it's included in the default john.conf). For wordlist mode, you can limit John to trying 12-character long candidate passwords only by defining and using an external filter().(Continue reading)
On Fri, Nov 09, 2007 at 05:39:12PM -0500, jmartinez@... wrote: > I wonder if there is a compiled binary version that works with NT hashes > from passwords longer than 8 chars (8-11 at least) You must be referring to the default compile-time length limitation of "incremental" mode. Please note that other cracking modes do not have this limitation, and you're not supposed to be artificially limiting JtR to using "incremental" mode only. All of the existing builds of JtR with support for NT hashes patched in should work for passwords longer than 8 characters - just not with "incremental" mode indeed. > or what changes I need to make to the source code and compile on cygwin. Please refer to these older postings for some relevant info: http://www.openwall.com/lists/john-users/2006/06/08/2 http://www.openwall.com/lists/john-users/2007/07/04/6 BTW, you will likely get much better performance at NT hashes by compiling JtR with a recent revision of the jumbo patch. -- -- Alexander Peslyak <solar at openwall.com> GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15 http://www.openwall.com - bringing security into open computing environments Was I helpful? Please give your feedback here: http://rate.affero.net/solar(Continue reading)
On Mon, Nov 05, 2007 at 03:43:55AM +0000, Larry Bonner wrote: > just wondering, is it possible to write bitslice implementation for > oracle hashes that use (new hash) sha-1 and > (older hash) des in cbc mode? if not, why not? I haven't looked into the Oracle hashes specifically, but in general: DES-based hashes can be efficiently and relatively easily bitsliced as long as the number of DES block encryptions per hash computation is fixed (for a given salt, if applicable). When that number is not fixed, implementation complexity increases dramatically and efficiency decreases, but an implementation is still possible (with buffering). CBC mode is not a problem for bitslicing (as multiple candidate passwords will be tested in parallel), although I am not sure what you mean by this mode being used for password hashing. (I am not familiar with Oracle password hashing.) As to SHA-1 (as well as MD4 and MD5, for that matter), bitslice implementations are possible, but they are only more efficient than traditional ones on CPUs with wide registers (say, 128+ bits), with large L1 caches, and/or with unusually(?) high instruction issue rates. Current general-purpose CPUs that satisfy these criteria happen to also support parallel operations on 32-bit elements within the 128-bit vector registers (SSE, AltiVec), which is both more straightforward and likely more efficient for these hashes. It has been many years since I've experimented with a bitslice implementation of MD5 - on an old Alpha (dual-issue, 64-bit) in 1998. It achieved about the same performance as a traditional implementation(Continue reading)
Hi Andrea, I am really sorry for not commenting on this earlier. In case this is a valid excuse, I had hoped my e-mails stack would not grow to 2 months when I postponed your messages at first. I appreciate your effort a lot, as well as your posting about it to john-users. Thank you! On Tue, Sep 18, 2007 at 06:25:06AM +0200, Andrea Arcangeli wrote: > I'm unsure about the license requirement, currently I used LGPL but it > may very well be I need to make the C part GPL, any advice is > welcome. I know LGPL may also be upgraded (or downgraded depending on > your point of view ;) to GPL at any time without my consent (this is a > property of the LGPL itself). Not sure if that matters in this case? My understanding is that your added source files can stay LGPL'ed (as if they were "libraries"), whereas your changes to JtR's files that you got under GPL v2 fall under GPL v2 terms. I actually appreciate your using LGPL rather than GPL v2 here as this leaves more flexibility for others who might update this code. > I'd also like to know if something remotely like the below could be > merged into john of if it has to remain separated (I included the > patch it in the cpushare core package for now). It's not so > invasive. However CPUShare is still in alpha status, the buy protocol > may change a lot over time and that will require updates ... I've been planning to re-work JtR source code before I add support for more hash types, etc. If I ever find the time for that (and I hope so!), then I'll definitely consider merging CPUShare support.(Continue reading)
the number of DES block encryptions for ORACLE are not fixed.
the algorithm (after looking at Simon Marechal's patch) is roughly..
where input buffer is $USER || $PASS in unicode format.
DES_key_schedule ks;
unsigned char des_key[8] = { 0x01,0x23,0x45,0x67,0x89,0xab,0xcd,0xef };
des_set_key(&des_key,&ks);
des_ncbc_encrypt((unsigned char*)input,len,&ks,(DES_cblock*)output);
des_set_key((DES_cblock*)output,&ks);
des_ncbc_encrypt((unsigned char*)input,len,&ks,(DES_cblock*)hash);
the number of block encryptions increases as the plaintext ($USER +
$PASS) get longer..so based on your comments, it appears bitslice
would provide
little or no advantage over normal code?
> As to SHA-1 (as well as MD4 and MD5, for that matter), bitslice
> implementations are possible,
have you got or know of any code that demonstrates it? to play around with.
> Maybe it's worth giving this another try
> on SSE2,
since CORE2, performance with SSE2 certainly improved, i think it
would be worth investigating too.
(Continue reading)
RSS Feed66 | |
|---|---|
72 | |
63 | |
146 | |
104 | |
138 | |
177 | |
78 | |
109 | |
168 | |
177 | |
175 | |
103 | |
150 | |
106 | |
87 | |
122 | |
90 | |
74 | |
47 | |
119 | |
186 | |
121 | |
56 | |
90 | |
53 | |
112 | |
129 | |
58 | |
50 | |
51 | |
53 | |
98 | |
94 | |
52 | |
47 | |
26 | |
39 | |
160 | |
99 | |
29 | |
70 | |
20 | |
38 | |
75 | |
52 | |
114 | |
49 | |
10 | |
14 | |
13 | |
43 | |
37 | |
19 | |
21 | |
54 | |
34 | |
36 | |
42 | |
46 | |
22 | |
37 | |
31 | |
51 | |
68 | |
10 | |
35 | |
10 | |
47 | |
10 | |
25 | |
19 | |
30 | |
39 | |
65 | |
38 | |
56 | |
47 | |
10 | |
55 | |
34 | |
40 | |
40 | |
82 | |
125 | |
148 | |
76 | |
80 | |
56 | |
52 | |
38 | |
41 | |
46 | |
42 | |
11 | |
47 | |
36 | |
2 | |
1 |
