300921 |
29-May-2016 |
allanjude |
Import the skein hashing algorithm, based on the threefish block cipher
Connect it to userland (libmd, libcrypt, sbin/md5) and kernel (crypto.ko)
Support for skein as a ZFS checksum algorithm was introduced in r289422 but is disconnected because FreeBSD lacked a Skein implementation.
A further commit will enable it in ZFS.
Reviewed by: cem Sponsored by: ScaleEngine Inc. Differential Revision: https://reviews.freebsd.org/D6166
|
300903 |
28-May-2016 |
allanjude |
Implement SHA-512 truncated (224 and 256 bits)
This implements SHA-512/256, which generates a 256 bit hash by calculating the SHA-512 then truncating the result. A different initial value is used, making the result different from the first 256 bits of the SHA-512 of the same input. SHA-512 is ~50% faster than SHA-256 on 64bit platforms, so the result is a faster 256 bit hash.
The main goal of this implementation is to enable support for this faster hashing algorithm in ZFS. The feature was introduced into ZFS in r289422, but is disconnected because SHA-512/256 support was missing. A further commit will enable it in ZFS.
This is the follow on to r292782
Reviewed by: cem Sponsored by: ScaleEngine Inc. Differential Revision: https://reviews.freebsd.org/D6061
|
299094 |
04-May-2016 |
ngie |
Merge ^/user/ngie/release-pkg-fix-tests to unbreak how test files are installed after r298107
Summary of changes:
- Replace all instances of FILES/TESTS with ${PACKAGE}FILES. This ensures that namespacing is kept with FILES appropriately, and that this shouldn't need to be repeated if the namespace changes -- only the definition of PACKAGE needs to be changed - Allow PACKAGE to be overridden by callers instead of forcing it to always be `tests`. In the event we get to the point where things can be split up enough in the base system, it would make more sense to group the tests with the blocks they're a part of, e.g. byacc with byacc-tests, etc - Remove PACKAGE definitions where possible, i.e. where FILES wasn't used previously. - Remove unnecessary TESTSPACKAGE definitions; this has been elided into bsd.tests.mk - Remove unnecessary BINDIRs used previously with ${PACKAGE}FILES; ${PACKAGE}FILESDIR is now automatically defined in bsd.test.mk. - Fix installation of files under data/ subdirectories in lib/libc/tests/hash and lib/libc/tests/net/getaddrinfo - Remove unnecessary .include <bsd.own.mk>s (some opportunistic cleanup)
Document the proposed changes in share/examples/tests/tests/... via examples so it's clear that ${PACKAGES}FILES is the suggested way forward in terms of replacing FILES. share/mk/bsd.README didn't seem like the appropriate method of communicating that info.
MFC after: never probably X-MFC with: r298107 PR: 209114 Relnotes: yes Tested with: buildworld, installworld, checkworld; buildworld, packageworld Sponsored by: EMC / Isilon Storage Division
|
298107 |
16-Apr-2016 |
gjb |
Merge the projects/release-pkg branch to head.
This allows packaging the base system with pkg(8), including but not limited to providing the ability to provide upstream binary update possibilities for non-tier-1 architectures.
This merge is a requirement of the 11.0-RELEASE, and as such, thank you to everyone that has tested the project branch.
Documentation in build(7) etc. is still somewhat sparse, but updates to those parts will follow.
Sponsored by: The FreeBSD Foundation
|
292782 |
27-Dec-2015 |
allanjude |
Replace sys/crypto/sha2/sha2.c with lib/libmd/sha512c.c
cperciva's libmd implementation is 5-30% faster
The same was done for SHA256 previously in r263218
cperciva's implementation was lacking SHA-384 which I implemented, validated against OpenSSL and the NIST documentation
Extend sbin/md5 to create sha384(1)
Chase dependancies on sys/crypto/sha2/sha2.{c,h} and replace them with sha512{c.c,.h}
Reviewed by: cperciva, des, delphij Approved by: secteam, bapt (mentor) MFC after: 2 weeks Sponsored by: ScaleEngine Inc. Differential Revision: https://reviews.freebsd.org/D3929
|
291325 |
25-Nov-2015 |
bdrewery |
META MODE: Avoid dirdep dependency on lib/libmd.
This avoids using the staged headers for sys/crypto/sha2/*.h, such as sha256.h, which added an unneeded pre-build dependency on libmd to libcrypt. This header is an INCS in lib/libmd, but found via .PATH in sys/crypto/sha2. Since the libcrypt build was already using the in-src libmd headers directly, just teach it how to find the sha256.h header as well.
Sponsored by: EMC / Isilon Storage Division
|
264964 |
26-Apr-2014 |
des |
r261913 broke DES passwords, because the only way they could work, since they don't have an easily recognizable signature, was if they were the default. This commit rewrites crypt_set_format(3) etc to address this:
- Use a pointer instead of an index to identify the default format. This pointer is initialized at compile time to point to the first first element in the list of supported formats, eliminating the need for crypt_setdefault(). Using a pointer also simplifies iterating through the list.
- Associate DES with the magic string "_", which takes care of the Extended DES format.
- Finally, as a special case, if the salt does not match any known magic string but matches ^[./0-9A-Za-z]{13}$, it is assumed to be a DES password and is passed on to crypt_des().
MFC after: 1 week
|
263218 |
16-Mar-2014 |
jmg |
replace the kernel's version w/ cperciva's implementation... In all my tests, it is faster ~20%, even on an old IXP425 533MHz it is ~45% faster... This is partly due to loop unrolling, so the code size does significantly increase... I do plan on committing a version that rolls up the loops again for smaller code size for embedded systems where size is more important than absolute performance (it'll save ~6k code)...
The kernel implementation is now shared w/ userland's libcrypt and libmd...
We drop support for sha256 from sha2.c, so now sha2.c only contains sha384 and sha512...
Reviewed by: secteam@
|
263161 |
14-Mar-2014 |
jmmv |
Make bsd.test.mk the only public mk fragment for the building of tests.
Change {atf,plain,tap}.test.mk to be internal implementation details of bsd.test.mk. Makefiles that build tests should now only include bsd.test.mk and declaratively specify what they want to build, without worrying about the internal implementation of the mk files.
The reason for this change is to permit building test programs of different interfaces from a single directory, which is something I had a need for while porting tests over from src/tools/regression/.
Additionally, this change makes it possible to perform some other requested changes to bsd.test.mk in an easier manner. Coming soon.
|
262945 |
09-Mar-2014 |
jmg |
various formating fixes, use NUL for NUL bytes..
drop out dated perf numbers (can't imagine people are still running Pentium MMX 166's anymore)...
bump date...
drop max length of salt of 8 since _PASSWORD_LEN is now large, 128.. and state the max length of the salt depends upon the module, sha-{256,512} have a max salt of 16..
recommend 8 characters of salt instead of just 2...
MFC after: 1 week
|
256761 |
19-Oct-2013 |
rpaulo |
Clearly split the logic to build ATF and plain tests apart.
This change introduces a new plain.test.mk file that provides the build infrastructure to build test programs that don't use any framework. Most of the code previously in bsd.test.mk moves to plain.test.mk and atf.test.mk is extended with the missing pieces.
In doing so, this change pushes all test program building logic to the various *.test.mk files instead of trying to reuse some tiny bits. In fact, this attempt to reuse some definitions makes the code harder to read and harder to extend.
The clear benefit of this is that the interface of bsd.test.mk is now clearly delimited.
Submitted by: Julio Merino jmmv google.com MFC after: 2 weeks
|
156813 |
17-Mar-2006 |
ru |
Reimplementation of world/kernel build options. For details, see:
http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061725.html
The src.conf(5) manpage is to follow in a few days.
Brought to you by: imp, jhb, kris, phk, ru (all bugs are mine)
|
70421 |
28-Dec-2000 |
peter |
Hindsight is wonderful, but I got cold feet over the crypt(3) default so I am backing it out for now. The problem is that some random program calling crypt() could be passing a DES salt and the crypt(3) library would encrypt it in md5 mode and there would be a password mismatch as a result. I wrote a validater function for the DES code to verify that a salt is valid for DES, but I realized there were too many strange things to go wrong. passwd(1), pw(8) etc still generate md5 passwords by default for /etc/master.passwd, so this is almost academic. It is a big deal for things that have their own crypt(3)-ed password strings (.htaccess, etc etc). Those are the things I do not want to break.
My DES salt recognizer basically checked if the salt was either 2 or 13 characters long, or began with '_' (_PASSWORD_EFMT1). I think it would have worked but I have seen way too much crypt() mishandling in the past.
|
70419 |
28-Dec-2000 |
peter |
Merge into a single US-exportable libcrypt, which only provides one-way hash functions for authentication purposes. There is no more "set the libcrypt->libXXXcrypt" nightmare. - Undo the libmd.so hack, use -D to hide the md5c.c internals. - Remove the symlink hacks in release/Makefile - the algorthm is set by set_crypt_format() as before. If this is not called, it tries to heuristically figure out the hash format, and if all else fails, it uses the optional auth.conf entry to chose the overall default hash. - Since source has non-hidden crypto in it there may be some issues with having the source it in some countries, so preserve the "secure/*" division. You can still build a des-free libcrypt library if you want to badly enough. This should not be a problem in the US or exporting from the US as freebsd.org had notified BXA some time ago. That makes this stuff re-exportable by anyone. - For consistancy, the default in absence of any other clues is md5. This is to try and minimize POLA across buildworld where folk may suddenly be activating des-crypt()-hash support. Since the des hash may not always be present, it seemed sensible to make the stronger md5 algorithm the default. All things being equal, no functionality is lost.
Reviewed-by: jkh
(flame-proof suit on)
|
51510 |
21-Sep-1999 |
dt |
Someone changed major numbers of the libraries from 2 to 3 for 0 (zero) reasons. Revert the major number back to 2.
libcrypt only export one function, before the recent changes and now: char *crypt(const char *key, const char *salt); The prototype didn't changed. Internal representation of `char' and `char *' didn't changed. Therefore, there is no reason to change the version number.
|
44947 |
23-Mar-1999 |
bde |
Simplified using new SYMLINKS macro, mainly to test this macro. The ifdefs are too ugly for this to be much of a simplification. The existence tests are even uglier now. Note that the previous commit was not submitted by me. It missed the point and just added a second layer of unused removals.
Fixed hard-coded "libcrypt"s. The LCRYPTBASE macro mainly makes things hard to read, but use it while we have it.
|
42981 |
21-Jan-1999 |
brandon |
Rewrite of crypt library to be more modular, and addition of the Secure Hashing Algorithm - 1 (SHA-1), along with the further refinement of what $x$salt$hash means. With this new crypt the following are all acceptable:
$1$ $MD5$ $SHA1$
Note: $2$ is used by OpenBSD's Blowfish, which I considered adding as $BF$, but there is no actual need for it with SHA-1. However, somebody wishing to add OpenBSD password support could easilly add it in now.
There is also a malloc_crypt() available in the library now, which behaves exactly the same as crypt(), but it uses a malloced buffer instead of a static buffer. However, this is not standard so will likely not be used much (at all).
Also, for those interested I did a brief speed test Pentium 166/MMX, which shows the DES crypt to do approximately 2640 crypts a CPU second, MD5 to do about 62 crypts a CPU second and SHA1 to do about 18 crypts a CPU second.
Reviewed by: Mark Murray
|
21673 |
14-Jan-1997 |
jkh |
Make the long-awaited change from $Id$ to $FreeBSD$
This will make a number of things easier in the future, as well as (finally!) avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been insane otherwise.
|
4246 |
07-Nov-1994 |
phk |
*** ATTENTION *** YOU MIGHT BE ABOUT TO BE HOSED *** ATTENTION ***
This effectively changes the non-DES password algoritm.
If you have the "securedist" installed you will have no problems with this. (Though you might want to consider using this password-encryption instead of the DES-based if your system is likely to be hacked)
If you are running a -current system without the "securedist" installed: YOU WILL NEED TO CHANGE ALL PASSWORDS !! There is no backwards mode.
Suggested procedure is: Update your sources cd /usr/src/lib/libcrypt make clean make all make install passwd root <set roots new password> change password for any other users on the system.
This algorithm is expected to be much better than the traditional DES- based algorithm. It uses the MD5 algorithm at what it is best at, as opposed to the DES algorithm at something it isn't good at at all. The algorithm is designed such that it should very hard to shortcut the calculations needed to build a dictionary, and to make partial knowledge (Hmm, his password starts with a 'P'...) useless. Of course if somebody breaks the MD5 algorithm this looses too.
The salt is 48 bits (8 char @ base64). The encrypted password is 128 bits.
And I am positively delighted to say that it takes 34 msec to crypt() a password on a Pentium/60Mhz, so building a dictionary is not really an option for hackers at the moment.
|