Hot answers tagged

14

bcrypt would be a somewhat better approach because it is designed to be (programmably) slow. Using a large enough salt and a reasonable complexityFactor, bcrypt(salt + number, complexityFactor) should yield a viable hash and you avoid "rolling your own cryptography", which could possibly turn out to be a difficult sell. To increase security you just crank ...


13

Backups, backups, backups. Have a good backup and restore strategy. You should be able to restore any server, network fileshare or desktop client to exactly the state it had yesterday, last week or last month (adjust these time increments according to your business needs). When you notice a malware infection, just nuke the affected system and restore it ...


8

Your friend is correct in that private key encryption is not the tool for the job. This answer on Cryptography.SE does a good job of explaining why. Some highlights: Any public-key encryption schemes is bound to increase the size of the data that it enciphers. While there are more efficient schemes, it is safe to say that a symmetric scheme is ...


7

Asymmetric cryptography has two common use cases: Encryption: You process a message or file with the public key of somebody else. Only he/she can decrypt it with his/her private key. Signature: You process a message or file with your own private key. The message or file itself can be transmitted unencrypted. It is common to process/sign only a hash of the ...


6

There are potentially other privacy issues you're not considering yet. By design your app makes it easy to see who is connected to a certain target. So an attacker creates one contact on their phone (the activist/informant/terrorist/victim they are interested in) and then connects to many other users through your app, to create a list of the target's ...


6

Yes, it is (a bit) flawed. The problem is that the space is too small, so even with the multiple rounds and salts, it's relatively easy to bruteforce. Open Whisper Systems had a witty system where they provided an encrypted bloom filter that can be queried locally using blind signatures. They explain the process (as well as providing a good discussion of ...


6

This is highly speculative, but, presumably, there would be much wailing and grinding of teeth. Then people would migrate to asymmetric cryptosystems that use elliptic curves. There would be some heavy business for CA; many SSH keys would have to be rolled over; and the PGP users would cringe first at the idea that anybody can impersonate them by forging ...


5

The most-authoritative reference on EMV replay (i.e., transaction cloning) is Peter Fillmore's latest talk from Syscan 2015 https://github.com/peterfillmore/Talk-Stuff/blob/master/Syscan2015/PeterFillmore_Syscan2015.pdf Another great resource is Ricardo Rodriguez's talk from Rooted 2015 ...


4

No. People with vested interests and deep wallets have put countless man-hours into solving this problem, even when using specialized hardware, and it gets broken over and over. Some game systems used security chips (10NES, anyone?) which validated cartridges and refused to run the system if the signatures did not match. It did not work out too well. If you ...


4

You are correct that by only using a MAC, an eavesdropper can read the message. This is because a MAC is designed, as you note, to protect message integrity, (as well as origin authenticity, hence the "authentication" bit of "message authentication code) not message confidentiality. If we want confidentiality, we use encryption instead. If we want (as we ...


4

Any answer to this will be pure speculation: there is no right answer. That said, my opinion is that OpenSSL is at least as good as any closed-source crypto library. Consider that github lists 175 contributors to the openssl project, and 1,442 forks, while google scholar finds 17,400 academic papers for "openssl". Go ahead and find me a closed-source ...


4

Explanations of AES start with bits because that's what AES, and more general encryption, does: it processes data which is a sequence of bits. We human beings have been representing information with another mechanism for more than 5000 years, with "glyphs", now often called "characters" (these two terms designate slightly different concepts but let's not ...


3

How can we do this in a cryptographically secure way and respecting the users' privacy (i.e. without sharing the numbers in plain-text between them or with a server)? tldr: You can't. Hashing is great for certain uses, but this is probably not one of them. The reason is that an attacker would know that there are only 10 billion possibilities (for ...


3

I am assuming a Linux system here, on some OS like FreeBSD and Mac OS there isn't any difference between /dev/random and /dev/urandom, and yet others don't have those devices Both /dev/random and /dev/urandom use the same entropy pool. The difference is that /dev/random "counts" how many bytes have been extracted, estimating the entropy left in the pool. If ...


3

There's no absolute barrier, but you can make it quite hard for malware, and do a lot more than just filter and backup. Think about what crypto-ransomware has to do, to succeed - it must: reach the system with the data (which includes getting past 3 hurdles - technological, policies and people) remain undetected execute (run) successfully put you in a ...


3

RHSM is the new x509 based PKI solution to their older RHN subscription manager. Unlike RHN which provided authorization only for registered systems, RHSM provides authentication, authorization and repudiation based on certificates. Those certificates rely on your typical asymmetric encryption making use of private and public keys to generate and sign the ...


3

Even though I think you might be referring to the secure key exchange process (for this, I suggest you have a look at Diffie-Hellman as an example) rather than to the public key specifically, I will answer the original question because I have always been taught not to divagate. There are three main ways you can exchange a public key with someone: ...


2

What you are describing is known as a Stream Cipher. As to the differences, the linked article can be cited to get you started: Stream ciphers are often used for their speed and simplicity of implementation in hardware, and in applications where plaintext comes in quantities of unknowable length like a secure wireless connection. If a block cipher (not ...


2

Can't we just make IV as unique and secret? Will it mean that the IV can now be treated as a secret Key? Key distribution is hard, and there's no reason to make the IV a secret. If Alice wants to send a message to Bob using symmetric encryption both must somehow already know the encryption key and the IV. To share the encryption key Alice and Bob ...


2

A good algorithm satisfies security requirements (e.g. a hash function needs to be collision resistant, preimage-resistant or a cipher needs to satisfy ciphertext indistinguishability) the tricky part here is how to justify that it satisfies the security requirements. We rely on security reductions (''proofs''), extent of external analysis (e.g. ...


2

As long as Bob keeps his private key secret you can simply encrypt everything which only Bob should see with Bobs public key. This also includes the signature, i.e. when sending a mail from Alice to Bob: encrypt the mail with Bobs public key make a detached signature for this mail using Alice private key encrypt this detached signature using Bobs public ...


2

IF (that's a big "if") the generator g and the public element from the peer can be assumed to be part of a subgroup of prime order, THEN it suffices for exponents to have size 2t bits, for a "security level" of t bits. In other words, 256 bits are fine. Now if p is a so-called "strong prime" (i.e. p is prime and (p-1)/2 is also prime), then any integer ...


1

Let's do some tests! I started with a naive bash implementation, and calculated 10k numbers in 33 seconds: #!/bin/bash phone="2125551212" salt="abcdefghijklmnopqrstuvwxyz" shasalt() { echo "$* $phone $salt" | sha512sum; } for f in {1..10000} do shasalt $(shasalt $(shasalt)) >/dev/null # or write to a file... ((phone++)) done echo ...


1

Given the thin details in the story it's hard to be sure, but the simplest explanation is the credentials were not encrypted when the hacker made a copy. The passwords might have been encrypted in a database, but many so-called 'transparent' database encryption schemes serve only to protect the database file from being copied and reused; they ...


1

Passwords should not be encrypted, they should be hashed. Encryption can be easily reversed if you have the key - and an attacker who has managed to steal the whole database probably has stolen the key as well. A hash can not be easily reversed. When someone attempts to login, the server does not decrypt the stored password. Instead it hashes the provided ...


1

The Key principle behind open source software is peer review. The idea is that many people (experts and amateurs alike) will review the code over time and that review process will lead to better, bug free code. So IMO yes, open sourced crypto algorithms are better than closed sourced algorithms for just this fact. However, both systems are still vulnerable ...


1

The list of open TLS 1.3 issues may give you some ideas. For example: Should SNI be encrypted to hide the server name to passive attackers? The issue states that this will complicate the handshake. Why is this the case? Maybe you can research the best way to implement this. Can the server request a proof of work from the client to prevent DoS attacks? ...



Only top voted, non community-wiki answers of a minimum length are eligible