On Win 2003 32 bit, I successfully export a PRIVATEKEYBLOB with a CryptExportKey call (dwFlags=0). Then I attempt to import the key blob on a Win Server 2008 64 bit with a 64 bit executable, the call to CryptImportKey fails with NTE_BAD_DATA.
In both cases the crypto provider is initialized with a call to
CryptAcquireContext(&hProv,
szContainer, NULL, PROV_RSA_AES,
CRYPT_MACHINE_KEYSET)
The passwords to export/import match. The public key is based on a CryptDeriveKey of an md5 hash of passwords that are identical in their plain text represetnation. I'm not sure whether the public keys end up being equal in the two systems.
Are the different types of systems (Win 2003 32 bit vs Win 2008 64 bit) the expected cause of failure, and is there a way of getting this to work?
As conjectured the public keys produced by ATL's CCryptDerivedKey were not equal on the two systems. The default settings of CCryptDerivedKey must be different in the two versions of ATL library.
Since I had access to both the source and destination servers, I could reexported and imported the key in a consistent manner - specifying algorithm, key size and presence of salt.
It would be nice to know what the exact settings of CCryptDerivedKey::Initialize method were in earlier version of ATL library (Visual Studio 2005, I believe).
Related
I am finding that all of my Azure App Setting keys are getting truncated to 64 characters in my application when I try to access them as environment variables. I have only found one website that documents this behavior. Every other website claims I should have a 10KB limit for the key/value together, so I am very confused about this rule to begin with.
My question is how can I work around this limitation? I use these app settings the way I thought Microsoft intended me to as configuration keys, but 64 characters is no where near long enough. I never encountered any kind of limitations like this with PCF.
64 Character Limit:
64 Character Limit Documentation
10 KB Limit:
10 KB Limit Documentation
Edit:
I got a question asking why my keys would be 64 characters, so let me explain. The .Net Core Configuration components allow you to declare configuration in json files and then override or augment those values using App Settings. It doesn't take too many levels of nested configuration objects to go over the 64 character limit.
Json File Containing:
{
"ParentConfiguration": {
"NestedConfiguration": "Value1"
}
}
Can override with App Setting named "ParentConfiguration__NestedConfiguration"
I have a Microsoft surface keyboard, it works over BLE 4.0.
I would like to pair it with 2 hosts, my macbook and a linux workstation.
The bluetooth dongle is inserted in a KVM switch, and I need it to be paired with one machine at a time.
There are plenty of tutorials on the internet which achieve a similar thing between Windows & MacOS or MacOS & Linux.
The general idea is to pair with both and then replace the pairing keys & some other parameters on the other hosts so they match.
MacOS settings for High Sierra are located in /private/var/root/Library/Preferences/com.apple.bluetoothd.plist
Linux(Arch) settings are in /var/lib/bluetooth/DONGLE_MAC/DEVICE_MAC/info
Keys which require synchronization are:
IdentityResolvingKey.Key
LocalSignatureKey.Key
LongTermKey.Key
LongTermKey.EDiv
LongTermKey.Rand
I have found a match for all of them, but a LocalSignatureKey. The matching pair on Windows is called CSRK, but I can't find a version of it on MacOS.
Apart from SMPDistributionKeys dictionary on Mac, which contains all the other keys from the list, I have some other top-level keys, which I hope may represent the CSRK/LocalSignatureKey:
MagicCloudPairingMasterHint
MagicCloudPairingMasterKey
SMPCloudLocalNonce
SMPCloudLocalPrivateKey
SMPCloudLocalPublicKey
Does anyone have an idea what would be the mapping for LocalSignatureKey on Mac? Or CSRK on Windows to Mac?
Our software runs on Linux and we need to create a mapping between Linux device name(something like /dev/sda1) and VolumeGUID as it appears in Windows, since we are examining Windows disks/partitions.
We get this information from MountedDevices Windows Registry subkey.
Problem occurs on Windows 2016, where Volume{GUID}s are no longer listed in MountedDevices subkey.
I managed to figure out, that Volume{GUID} is not a random GUID anymore(which is probably why they do not have to be stored it registry anymore), but it gets composed from data in the partition table.
In case of GPT, the VolumeGUID is actually a GPT partition GUID, which is great, because I can easily reconstruct those VolumeGUIDs.
In case of MBR, it is something like:
\?\Volume{46e21ed5-0000-0000-0000-100000000000}\
\?\Volume{46e21ed5-0000-0000-0000-104000000000}\
\?\Volume{46e21ed5-0000-0000-0000-108000000000}\
\?\Volume{46e21ed5-0000-0000-0000-20c000000000}\
...
Where 46e21ed5 is actually a disk signature, but I'm not sure what other fields mean. It looks like there's a partition offset (0x400 = 1024, and each partition is 1024MB in the provided example), but something does not add up for the last partition which has 20C00.
Does anyone have more information on this subject and how these volume GUIDs get composed? (Google does not find any information on this subject)
Regards
What is the procedure for generating the Initial Sequence Numbers (ISN)
in LINUX tcp/ip protocol. I know the procedure for ISN generation in
the LINUX kernels 2.4 to 2.6 that are described in pages 7 & 8 of
Embedding Covert Channels into TCP/IP. I have searched for similar
procedures in later kernels, but to my dismay I couldn't find any. I understand that much details may not be available for obvious reasons related to security. As I'm verifying the possibilities of implementing a similar steganography scheme(as described in the link) in the later Linux kernels, I am badly in need of some information. Any help is appreciated.
Read my answer here:
Most efficient way to manipulate ISN numbers in TCP headers
This algorithm is used on the latest kernel TCP Stack (3.5).
EDIT : See image below to see all concerned kernels versions
EDIT2 : See the sources of the kernel for older versions of the function secure_tcp_sequence_number:
Kernel 2.4.22
Kernel 2.6.30
Kernel 2.6.39
Kernel 3.0
Kernel 3.1 : (MD5 has replaced half-MD4)
After more careful reading of RFC6528 and RFC1948 I came to a conclusion that the algorithm for generating Initial Sequence Numbers(ISNs) as specified in RFC1948 :
ISN = M + F(LocalIP, LocalPort, RemoteIP, RemotePort, Secretkey)
has not changed. Instead, the algorithm which was proposed by Bellovin S.M in RFC1948 is formally specified and taken into the Standards Track(as per RFC2119) in RFC6528 which was written together by Bellovin S.M and Gont. F.. As the now obsolete RFC1948 can't be used in any documentations, RFC6528 has replaced it.
But as pointed out in the answer to my original question MD5 has replaced half-MD4 as the Hash Function from kernels 3.1. This is completely justified by RFC6528 as it did give the flexibility to change F() which is the Pseudo-Random function.
(Please have a look at the links for more details).
Update to previous answers so that to represent current state (2019 and Linux kernel 5.1.3) because algorithm to generate ISNs in the kernel was changed again to be more secure.
secure_tcp_seq now uses SipHash (add–rotate–xor) functions to generate ISN based on initial secret key, source and destination IP address and port. I suppose this change was related to hash collision vulnerability resulted in hash flooding attacks.
Imagine a NIS user database /var/yp/input-files/passwd consisting of old crypt DES hashes. The aim is to migrate this database to md5 or sha hashes. When changing a password using yppasswd, it is generated using the same algorithm as for the existing entry (probably for legacy reasons), i.e. crypt stays crypt, md5 stays md5.
Our current plan is to write a special password change script wrapping yppasswd. Is there a more elegant way to tell yppasswd to generate changed passwords in md5 format by default?
I figured it out by now:
Download the nis-package of your distribution e.g. apt-get source nis under Debian.
Edit corresponding yp-tools-2.9/src/yppasswd.c
Replace int has_md5_passwd = 0; by int has_md5_passwd = 1; in the beginning of int main (int argc, char **argv)
yppasswd then always creates md5 hashes.
Recent Linux distributions support NIS password updates through PAM, which means you can use the local passwd program instead of yppasswd. This also means that you can configure the hash algorithm, which is still (as of yp-tools 2.12) not possible with yppasswd.
Your system should have an /etc/pam.d/passwd file, which will either contain or, more likely, refer to another file that contains a line of the form:
password sufficient pam_unix.so md5 nis
The second field might differ, and there might be other parameters at the end, but you want the password line that loads pam_unix.so and it should have at least the nis parameter as well as a hash function appropriate to your NIS server (md5, sha256, etc.)
Your distribution might have a better way of configuring this, though, so make sure your changes aren't going to be overwritten by an automated process later.
On RedHat-derived systems (including at least RHEL, CentOS, Scientific Linux, and Fedora), you need to use the authconfig program with at least the --enablenis parameter. For the above scenario with MD5 hashes, the following command line would be sufficient:
authconfig --enablenis --usemd5 --update
On Debian systems (and possibly Debian derivatives, but I can't check at the moment), the proper way to do this appears to be to copy /usr/share/pam-configs/unix to something else (say, /usr/share/pam-configs/nis), edit the new file to give it appropriate settings and a new profile name, then run pam-auth-update, disable the "Unix authentication" profile and enable your new profile.