Re: only password encrypted, all other data unencrypted!

<qazmlp1209@xxxxxxxxxxxxxx> wrote in message
news:1174454624.688163.204510@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Mar 21, 5:42 am, Unruh <unruh-s...@xxxxxxxxxxxxxx> wrote:
If you told us what problem you were having or trying to solve maybe we
could help you more. The standard is to encrypt everything. Why is that a
problem?- Hide quoted text -
The usecase is related to the LDAP client authentication to the LDAP
server. We do not have any stringent requirement of en/decrypting the
data(except the password that is used for LDAP authentication) that we
send over the LDAP connection. Hence, we require a simple, but
considerably safer(by encrypting the password) mechanism for it.

Ok, so let me make sure I understand the situation correctly first. You need
to make sure that at some point there was a user involved who is
authenticatable, but you don't need to make sure that the user actually
desired the actions included? Additionally, you have no need to keep the
actions secret? (substitute service for user as needed) Assuming this is
correct, it is an admittedly unusual situation, and I doubt that it is
really is what need security-wise, and you really should just transfer the
whole thing over SSL it will save you headaches later on, just remember it
wasn't me that certified this as secure, I believe there are great big holes
to walk through in the security, but:
Server S has a known and trusted public/private DH/ElGamal key pair KP_S
(These can be explained easily enough if needed)
When the Client C wants to connect C generates a one-time key pair KP_C
using the same field as KP_S
C->S KP_C
C & S both generate the shared secret SS
EK = SHA256(SS | "Encryption Key") ( | is concatentation)
MK = SHA256(SS | "MAC Key")
C MACs passphrase P using MK and appends the MAC to the passphrase to create
MP (MACd Passphrase)
C encrypts MC using EK to create EMP (Encrypted MP)
C->S EMP
S decrypts EMP with EK delivering MP
S verifies MAC on MP verifying that P has not been altered in transit

Assuming you choose the ElGamal parameters properly, and use well
established secure algorithms and chaining modes (256-bit AES, CBC-MAC for
MACing, CTR for encryption) this should transfer the passphrase safely.

For those of you familiar with the other meaning for EMP, yes I chose the
abbreviation deliberately because I feel that this is about as safe as
hitting the server with the other kind of EMP.
Joe


.

Relevant Pages

  • Re: Signing LDAP Without Certificate Services
    ... This is using the feature of Windows SSPI authentication to sign and encrypt ... XP and higher, Kerb, NTLM and Digest all support this with 128 bit cipher ... you can't use SSL LDAP connection in conjunction with the SSPI ... Note also that Windows clients have the ability to sign and encrypt LDAP ...
    (microsoft.public.windows.server.active_directory)
  • Re: only password encrypted, all other data unencrypted!
    ... The standard is to encrypt everything. ... The usecase is related to the LDAP client authentication to the LDAP ...
    (sci.crypt)
  • [NEWS] RTS CryptoBuddy Multiple Encryption Implementation Vulnerabilities
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... and encrypt their files and data. ... its passphrase and general encryption techniques. ... Attack: "Symmetric key injection". ...
    (Securiteam)
  • Re: GC and security
    ... Just what attack are you trying to protect against, ... comes back at end to encrypt and then app is done. ... getting rid of the need for a passphrase? ... There was some questions (from MySQL pro) about how MySQL writes would ...
    (comp.lang.python)
  • Re: GC and security
    ... comes back at end to encrypt and then app is done. ... gpg is fairly careful about passphrases. ... passphrase in the Python app instead of letting gpg handle it? ...
    (comp.lang.python)