Update README.md
authoradouble42 <adouble4242@gmail.com>
Wed, 9 Nov 2016 08:02:46 +0000 (03:02 -0500)
committerGitHub <noreply@github.com>
Wed, 9 Nov 2016 08:02:46 +0000 (03:02 -0500)
README.md

index e3cdef1..369bd81 100644 (file)
--- a/README.md
+++ b/README.md
@@ -2,7 +2,7 @@
 nemesis is a freebsd and Mac OS X (tested through 10.11) port based on TrueCrypt, i'm slowly rebranding it to comply with the original license but that is probably my least favorite task. which is not to say i didn't have some fun with it...whereever it is my right to dictate, the 2 clause BSD license shall apply.<br>
 TAKE HEED: TAKE WARNING: TAKE HEED:<br>
 <b>AES is headed for the chopping block - it doesn't belong here. call me paranoid, then read about bSafe, and if you're fine with keeping your data under one algorithm developed by the NSA, we are not in agreement, there are excellent alternatives available. Move to the Serpent-Twofish-Camellia chain, with the BLAKE-512 hash, the performance cost is negligible on modern hardware. also, expect the 256 bit hashes to be removed - and replaced, with 256 bit memory hardened versions based on (but very much NOT yescrypt) - this hash change, is imminent, as in it's my current project. AES will be removed when i replace it with another cipher, selected for use in a new combiner to replace one of the combinations involving AES. that could be a while as i haven't given it all the thought yet. but do take note, if you use the 256 bit hashes, change that up. when i break everything, i'll put a link to the last commit with support up for stragglers. if you are using Whirlpool or the BLAKE-512 hash you are good, they are not leaving. this project isn't about beating a dead horse for eternity. i've made clear my feelings on AES from the start.<br></b>
-as of 11/8 the OS X build is significantly less headachey, and as a result of that work, wxWidgets-3.1.0 is included in the source tree, similar to the original configuration. by default the project builds as a statically linked version again. undefine WX_STATIC in the Makefile to use a dynamic system wide install, 3.0.2 should work fine if you already have it. install OsxFuse 3.5.3, from the website, not ports, not brew, make sure to enable the compatibility layer during installation.<br>
+as of 11/8 the OS X build is significantly less headachey, and as a result of that work, wxWidgets-3.1.0 is included in the source tree, similar to the original configuration. by default the project builds as a statically linked version again. undefine WX_STATIC in the Makefile to use a dynamic system wide install, 3.0.2 should work fine if you already have it. install OsxFuse 3.5.3, from the website, not ports, not brew, make sure to enable the compatibility layer during installation. ports or brew versions of OsxFuse may work but i don't know about that and i'm not going that route again without good reason.<br>
 then, to make your final osx build: go to nemesis source directory; "make wxbuild; make" and you will have an application  sitting in Main/, linked against current Fuse and wxWidgets libs, without going through a bunch of package managers and headaches and annoyance.<br>
 it goes without saying i take back what i said about binary releases and i'll be providing one for OSX 10.7+ shortly.<br>
 because hot coffee, obligatory warning not to use this with windows secure boot. as it is right now it may allow some impossible permutations of hash and encryption algorithm if it builds at all and i have no means of testing so don't trash your disk and blame me. my goal isn't a windows boot application.<br>
This page took 0.024353 seconds and 4 git commands to generate. Download a nemesis OSX (sierra+high sierra, tested/working) binary, with fuse-ext3 via e2fsprogs, at this link. application and installer are signed by screwjack, llc. must install fuse with macFUSE layer first.