a question about OpenLDAP.
Where can I find some informations about OpenLDAP supported password encryption algorithms on last version (2.4.35)?
There isn't any such information. OpenLDAP doesn't encrypt passwords. It hashes them.
Related
Which of these methods of hashing passwords will be most secure and most hard to find hash collisions?
MD5 only
SHA1 only
MD5 over SHA1
Neither of these should be used for password hashing they have been proven to be insecure:
MD5 from Wikipedia:
The security of the MD5 has been severely compromised, with its weaknesses having been exploited in the field, most infamously by the Flame malware in 2012. The CMU Software Engineering Institute considers MD5 essentially "cryptographically broken and unsuitable for further use".
SHA1 from Wikipedia:
SHA-1 is no longer considered secure against well-funded opponents. In 2005, cryptanalysts found attacks on SHA-1 suggesting that the algorithm might not be secure enough for ongoing use,[3] and since 2010 many organizations have recommended its replacement by SHA-2 or SHA-3.[4][5][6] Microsoft,[7] Google[8] and Mozilla[9][10][11] have all announced that their respective browsers will stop accepting SHA-1 SSL certificates by 2017.
Much more secure hashing algorithms exist such as SHA-2 or 3 which should be considered.
I've got a situation where the source system has PGP installed, and they can only encrypt the file with PGP tool, and Target System has GPG installed, and we can decrypt only using GPG. is is possible to accomplish this functionality ?
The thing with encrypting is the encryption algorithm you're using. These algorithms are published and documented - and that means anyone can write code to implement it.
PGP is a piece of software written to implement a crypto algorithm. GPG is the Gnu implementation of the same.
So there's no reason to think this wouldn't work - as long as you use an algorithm that both products support. I believe GPG has more options than PGP.
From:
http://en.wikipedia.org/wiki/GNU_Privacy_Guard
As of versions 2.0.26 and 1.4.18, GnuPG supports the following algorithms:
Pubkey: RSA, ElGamal, DSA
Cipher: IDEA (from 1.4.13/2.0.20), 3DES, CAST5, Blowfish, AES-128, AES-192,
AES-256, Twofish, Camellia-128, Camellia-192, Camellia-256 (from 1.4.10/2.0.12)
So as long as your encrypting application uses one of these it should work fine. (RSA is probably a pretty good bet.)
Currently i am encrypting sensitive files using the following OpenSSL Command:
openssl aes-256-cbc -a -salt -in large_file.zip -out large_file.zip.enc
and to decrypt:
openssl aes-256-cbc -d -a -in large_file.zip.enc -out large_file.zip
This is working fine so far, but being as i don't have much experience with encryption and cryptography i'm looking for some insight into if this is the best way to do things.
Am i encrypting/decrypting the file correctly?
Am i making full use of AES-256 this way?
Am i doing something wrong here that may impact the security of the encrypted file?
Comments/Replies are greatly appreciated.
Daniel.
PS: I'm not quite sure if this belongs in superuser or stackoverflow, please advise.
It can be secure, given the password is secure enough, and given that you only expect confidentiality. It is impossible to say if anything is secure without the use case, threat model and specific system setup though.
The OpenSSL password based key derivation methods are secure, and so is AES-256 in CBC mode. That said, modern crypto often uses some kind of integrity/authentication as in a secure mode of encryption such as GCM or by adding a MAC (using a separate key).
It's more something for http://security.stackexchange.com, although you may get closed/voted down if you don't show enough research etc.
In the following MSDN page it states the encryption algorithms that are supported by BizTalk 2010
http://msdn.microsoft.com/en-us/library/aa559843(v=BTS.70).aspx
"BizTalk Server supports RSA and Diffie Hellman encryption certificates.
BizTalk Server supports Data Encryption Standard (DES), 3DES, and RC2 encryption algorithms."
My question is - Can BizTalk also support SMIME messages encrypted using the newer AES encryption algorithm?
3DES is getting quite old now and is getting replaced by AES so I'm wondering if BizTalk has built in support for it yet?
Thanks.
I've finally got an answer that Biztalk does not currently support AES encryption.
We are now looking into alternative workarounds to solve this issue..
Is one more secure than the other?
id_rsa.pub and id_dsa.pub are the public keys for id_rsa and id_dsa.
If you are asking in relation to SSH, id_rsa is an RSA key and can be used with the SSH protocol 1 or 2, whereas id_dsa is a DSA key and can only be used with SSH protocol 2. Both are very secure, but DSA does seem to be the standard these days (assuming all your clients/servers support SSH 2).
Update: Since this was written DSA has been shown to be insecure. More information available in the answer below.
SSH uses public/private key pairs, so
id_rsa is your RSA private key (based on prime numbers), which is more secure than your id_dsa DSA private key (based on exponents). Keep your private keys safe and share your id_rsa.pub and id_dsa.pub public keys broadly.
DSA is insecure
DSA has a guessable parameter if your computer's random number generator is sub par, which will reveal your secret key. ECDSA (DSA's elliptical curve upgrade) is similarly vulnerable. Even with good random numbers, DSA has other strength concerns/🎬 (these are also found in Diffie-Hellman).
OpenSSH creates insecure 1024 bit keys(workaround) and now disables DSA by default.
Prefer Ed25519
Elliptic curve cryptography offers increased complexity with smaller key sizes. Ed25519 (based on the complexity of plane-modeled elliptical curves) is the preferred implementation due to its assumed lack of meddling (leaked documents show that the US NSA weakens crypto standards).
Ed25519 was introduced in OpenSSH 6.5 (2014-01-30) and GnuPG 2.1 (2014-11-06) and became the default ("first-preference") in OpenSSH 8.5 (2021-03-03). Older systems may not yet accept Ed25519, but the list of supported implementations has been growing steadily.
Use RSA with 4096 bits when Ed25519 is unavailable
RSA key sizes of 4096 bits should have comparable complexity to Ed25519.
Ed25519 is still preferred to RSA due to a worry that RSA may be vulnerable to the same strength concerns as DSA, though applying that exploit to RSA is expected to be considerably harder.
rsa is considered more secure.
Not anymore (May 2020, ten years later), with OpenSSH 8.2, as reported by Julio
Future deprecation notice
It is now possible1 to perform chosen-prefix attacks against the SHA-1 hash algorithm for less than USD$50K.
For this reason, we will be disabling the "ssh-rsa" public key signature algorithm that depends on SHA-1 by default in a near-future release.
(See "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust" Leurent, G and Peyrin, T (2020) )
This algorithm is unfortunately still used widely despite the existence of better alternatives, being the only remaining public key signature algorithm specified by the original SSH RFCs.
The better alternatives include:
The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512.
These algorithms have the advantage of using the same key type as "ssh-rsa", but use the safe SHA-2 hash algorithms.
These have been supported since OpenSSH 7.2 and are already used by default if the client and server support them.
The ssh-ed25519 signature algorithm.
It has been supported in OpenSSH since release 6.5.
The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521.
These have been supported by OpenSSH since release 5.7.
To check whether a server is using the weak ssh-rsa public key algorithm for host authentication, try to connect to it after removing the ssh-rsa algorithm from ssh(1)'s allowed list:
ssh -oHostKeyAlgorithms=-ssh-rsa user#host
If the host key verification fails and no other supported host key types are available, the server software on that host should be upgraded.
A future release of OpenSSH will enable UpdateHostKeys by default to allow the client to automatically migrate to better algorithms.
Users may consider enabling this option manually.
Yes, rsa is considered more secure.
In October 2014, OpenSSH 7 (the default with Ubuntu 16.04LTS) has disabled default support for DSA. Take this as a strong sign that DSA is not a recommended method anymore.
https://www.gentoo.org/support/news-items/2015-08-13-openssh-weak-keys.html
One uses DSA and one uses RSA.