Tag Info

New answers tagged

0

There's also the cpuid utility available on a number of OS's. cpuid | grep -i aes AES instruction = true


1

To put it simply, an attacker can create an executable that has an encrypted virus inside of it. When the executable is downloaded to the victims machine it is not detected as a virus because the bad part is encrypted. When the user clicks on the file, The outer executable will load the encrypted data in memory and decrypt it, then execute it, all using RAM ...


2

Your private key is encrypted with Triple DES. While DES is easily broken, Triple DES is safe for now, especially in this context. AES was made to replace Triple DES not so much because Triple DES was broken, but because it was way too slow. In the context of private key encryption, a non issue.


3

Why is there des-ede3-cbs in my rsa private key? Because your private key is encrypted with that. As far as I know "DES" is an encryption standard from the seventies and it's considered broken. Yup. Pretty much. Consider reencrypting it with AES like so: $ openssl rsa -in desencryptedprivkey.pem -out aesencryptedprivkey.pem -aes128 EDIT ...


2

Executable file encryption is rather obfuscation than real encryption, since encrypted file still have to execute. So "decryptor" part has to know the decryption algorithm and/or key. Antivirus software has: various emulators, for x86 code, x64 code, normalized JavaScript code etc. various decryptors/unpackers for all "crypters" and archives known to ...


2

Is cryptography legal in India? Yes, it is legal. If yes, then what type of encryption is not allowed? Short answer is that there is no specific standard. I found this website that explains various facts. I would recommend to go through it. The [Department of Telecommunications (DoT)] is responsible for deciding what bits are allowed to route ...


1

As of today, India does not have any clear and well established laws and policies regarding encryption or encryption techniques to secure electronic communication. The extant laws only prescribe for use of such encryption standards or algorithms which are well established and in conformity with the international standards. As per Rule 5.2(6) of the ...


0

A Javascript Crypto API spec that all browsers must (hopefully) support. Am i correct? Hopefully all browsers should support it, though currently it's still work in progress. The specification does not mandate that the API be implemented in JavaScript. Developers are free to choose their underlying implementation, it could be JS, or a built in part of ...


1

For a cipher each key defines a different permutation, but that doesn't mean that there cannot be identical 1:1 relations. Take AES-256, which maps 2^128 values to another 2^128 values using a 256 bit key and you encrypt one 16 byte plaintext, say all zero's. The output will also have 2^128 values. So there must be keys that map the same plaintext to the ...


-1

The website is using Sha1 certificates to provide security so the new chrome browser is showing it as week algorithm because most of the organizations already migrated to SHA2 certificates. it's just a warning it does not mean that its a non-secured connection.


1

According to CryptDeriveKey() documentation, upper WORD of dwFlags parameter specifies desired key size in bits. In your case it should generate 40-bit (0x28) keys, effectively discarding all but first five bytes of the MD5 output. To achieve similar behavior with CommonCrypto you can try this: CCCryptorCreate(kCCDecrypt, kCCAlgorithmRC4, 0, ...


0

I wouldn't have thought this was a good idea. The TPM can only provide "trust" for keys that were created within the TPM. Otherwise, who knows what happened to the keys before they were added to the TPM? If the private key ever exists outside the TPM, all bets are off.


0

This here is where the linguistic descriptive abilities of the english language fails. Diffie helman is resistant to mitm iff an out of band third party entity is able to help in distributing keys and/or verifying the identity. You'll find in the literature, what it mostly defines is a connected web of trust surrounding the identity of the recipient or in ...


1

DH is not generally resistant to Man in the Middle attacks. If Alice and Bob (A<->B) can set up a shared secret. Then Frank can setup a shared secret with Alice (A<->F) At the same time Frank can set up a second (different) shared secret with Bob (F<->B). Frank can then decrypt A-> F messages and re-encrypt and send to bob F-> B & vice versa. ...


1

Apple uses such a mechanism on iCloud. I believe this is how it works (if memory serves me right), and slightly different from what others have suggested. As far as I understand it, it involves only asymmetric encryption. 1) The device (iPhone, iPad etc.) generates a key pair (device key). 2) For a new iCloud account, the device generates a second key pair ...


2

TL;DR: Generate a data-key pair, encrypt the private part with the public key of all users that have write access, encrypt the public part with the public key of all users that have read access. Let's tackle this one by one: Data must be securely encrypted in the database This is to secure against attackers, and mainly for the users to know ...


2

The generic methodology for this kind of problem is reasoning in terms of knowledge and indirection. You want each user to be able to do some things that other users, or the "tech people", cannot do; therefore, each user must know a secret value that other people do not. The user's password can be such a secret; otherwise, you would need something stored on ...


2

After a DH key exchange, both parties know what key they've computed. If no man-in-the-middle has infiltrated the connection, both parties will have the same key. If the connection has been breached, they will have different keys. If there is a means by which one party can ask the other what key it is using, the man in the middle will only be able to ...


0

If your threat model means your code has to run on a computer you can't trust, there is no way to protect your data: it simply isn't possible. No matter what you do, the decryption key MUST be present in the memory of the system performing the decryption in order to access the data. This means that the only possible way to protect the key is to move that ...


1

This is an interesting problem but has actually been solved in various open-source applications at this point. I would recommend, for your use case, borrowing from ownCloud's encryption model (which has the benefit of being open-source). The general application of this model on your software would look like: 1) Of course this can be done in many ways, ...


47

Tom has provided a good explanation as to why Diffie-Hellman cannot be safe against man-in-the-middling. Now this answers the OP's original question but probably leaves some readers with the (reasonable) follow-up question: Why don't we just use public-key (asymmetric) cryptography to ensure the confidentiality of our messages, and drop D-H altogether? There ...


120

Diffie-Hellman is a key exchange protocol but does nothing about authentication. There is a high-level, conceptual way to see that. In the world of computer networks and cryptography, all you can see, really, are zeros and ones sent over some wires. Entities can be distinguished from each other only by the zeros and ones that they can or cannot send. Thus, ...


0

I think there is one aspect of this comparison that was overlooked. user185 came close but didn't quite get there. I agree that these are apples and oranges and feel a better apples to apples comparison to be HTTPS and SSH. HTTPS and SSH utilize different layers of the OSI model and therefore encrypt the data at different times in the transmission. Then ...


2

In CBC mode, the IV is ALWAYS the same size as the block size used by your encryption algorythm. Thus, if you use AES, your IV will have to be of exactly 128 bits, regardless of the size of the data you have to encrypt. So, the proper way to encrypt your data in CBC mode is to: Divide your data in blocks of the appropriate size (128 bits for AES) bits If ...


0

I would say; A generate a pseudo random token encrypt using the word as the key send result B decrypt generate next token using predefined method encrypt it send it back A decrypt check received token (now A has authentificated B) if not ok then stop here generate next token encrypt it send to B B decrypt check With this you don't have ...


7

There are a few reasons to use larger keys. Your quote only mentions brute-force attacks against symmetric keys. If there is a weakness in the algorithm, then there are faster attacks than brute-force. That is a good reason to design algorithms with some safety margin such that it doesn't get broken as soon as somebody finds a little weakness in the ...


3

Key with a strength of 128 bits or higher are currently considered impossible to break. However, that doesn't necessarily mean that the key itself is 128 bit. The key size is related to key strength, but it doesn't even have to be linear with the key strength. Take for instance RSA; you need a 15K bit key to be near 256 bit security. The best way to see how ...


17

Your quote describes symmetric key strength, but your counter examples (1024, 2048 bits) reference keys used for asymmetric cryptography. The number of bits required for strength is different between the two. Your quote is from section 7.1 of Applied Cryptography; if you move ahead to section 7.2, for example, you'll see Schneier's predictions on what ...


0

PCI standards exist for a reason. While the process of achieving that level of security may be arduous, it is necessary to protect your client's data. Let's be clear about that; it's not just your data, it is data that your clients have entrusted to your care, and if you fail to secure it using reasonable best practice, your company is opening itself to ...


3

SSL/TLS is the encryption layer between browser and server. As long as you have properly configured your SSL/TLS on the server, any additional javascript type encryption is redundant. If you are trying to create a secure application, and your team does not understand what SSL/TLS does, you might want to consider bringing in a security consultant to help ...


1

From the OP's comments it doesn't sound like this would be useful to them, however, it may be useful to others. It's possible to usefully encrypt information client side, but the use cases are few and far between. Example use case: The user needs to work on confidential (as least by their judgment) documents which must be stored locally (perhaps to lower ...


13

JavaScript cryptography is not a good idea JavaScript cryptography is not bad per se, it's just ineffective against most commonly considered threats. If you consider a man-in-the-middle (MITM) to be a threat then SSL/TLS is a much more effective control as otherwise the attacker could substitute the JavaScript for a version which doesn't use ...


2

Have you think to use SSL/TLS on server side. So the data will traverse over secured channel. And on server side later you can encrypt ti and store it in such form in the database


4

PBKDF2 is a password hashing function(*); it uses a configurable number of iterations (to make it as slow as is appropriate) and a salt (to deter all kinds of parallelism in attacks). To verify a password, the hash is recomputed, and should yield the same value. To perform this recomputation, you need to use the same number of iterations and the same salt ...


2

Basic password hashing with salts only involves the password and a random salt that are joined together before creating the hash. You don't mention that joining process in your explanation and it's important because otherwise the salt doesn't add any security. The example you've linked to is using a more advanced type of password hashing using PBKDF2 which ...


0

Look into brute force factorization. If you can leverage a weakness in the PRNG then your factorization time is substantially diminished.


3

This sounds like the perfect use of an HMAC. You create a secure random secret S. Then the ticket for each page will be ID + HMAC(S, ID). When you get a ticket you extract the ID, redo the HMAC and then compare your result with that in the ticket. While this is likely be simpler and faster than an encryption solution, it will only work if you don't mind ...


1

Looks to me like standard public-key crypto should work. For example, using RSA (with public key N=p*q and e, private key d): S would be your private key d. Transforming: B = A^e mod N. Transform back: B^d = B mod N. Your requirements seem to then naturally fit the security assumptions of RSA. The one wrinkle here is that anyone can compute B from a ...


3

There are a few ways to do this. You can come down to the following statement: For authentication you can only use something the user knows, has or is. As you're in a file-encryption scenario, this should rule out most points concerning "what a user is", because they involve biometrical data, which needs to have tolerances. A password or passphrase. ...


0

in the CGA protocol in section 7.2 RFC3972 the technique is called hash extension. It seems to be a method used particularly for CGAs and seems not to be well known in other scenarios.


-1

Hashing is definitely the way. If brute-forcing is an issue then there is no secure way to do this, as any algorithm which compares two 5-letter strings and returns equivalence could be trivially brute-forced in a maximum of 26^5=11881376 comparisons. The only feasible way of defending against brute-forcing in such a low-entropy environment is to use a ...


4

The problem you are asking about is called the Socialist Millionaire problem and has been discussed in research before; as far as I know there is a protocol to do this comparison without disclosing any of the two secrets and without involvement of a third party. I will edit my answer with a full explanation as soon as possible.


3

As far as I do understand, you want to convert an authentication subkey to an SSH key, and authenticate using this. If I generate a PGP subkey that only has the authentication capablity and use this to generate an SSH keypair to authenticate Git for example, does this pose a security threat? Whether this is reasonable or not depends on what you're ...


5

The problem is probably not so much algorithmic security. The problem is that if there is a security problem with one of the applications that you also have a security problem the other application. Furthermore, it may be that some kind of attacks on the protocol may be made possible because you share keys. In other words, this is not a good idea with ...


1

Maybe sort of. The DUKPT algorithm is defined to use "two-key triple-DES", or formally TDEA Keying Option 2 from SP800-57 or originally FIPS46-3. Every key in this algorithm (BDK, device initialization key(s), future keys, and working key(s)) is a "double-length key" consisting of two classic-DES (DEA) keys, each 56 real key bits plus 8 bits reserved for ...



Top 50 recent answers are included