New answers tagged

1

With Isemis mention of "probability of false positives" I thought about Zero-knowledge proof. This answer makes no claims to be secure as it was never reviewed, so others should review and comment it. I am no professional security expert either and I didn't have the time to make sure the low number of possible phone numbers might be a problem. User A and ...


0

Why hash them? Why not encrypt instead, and send them to your own server. That way neither client device has to have access to each other's contacts, and the server does most of the work. This does introduce a single point of failure though, the server. If it was compromised, the attackers could potentially access all numbers. This could be controlled if ...


4

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 ...


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 ...


8

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 ...


7

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 ...


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 ...


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 ...


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 ...


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 ...


0

I'm sorry you don't need the private key to "decrypt" something encrypted using asymmetric encryption, you need the public key, which is in the certificate, or the certificate of the trusted authority. Using the public key also provides proof that the private key was indeed used. See this prior entry Digital Signature and Verification? and this: how ...


0

I mostly agree with @flihp, but some "tutorials" here and there suggest to use /dev/urandom as the hardware entropy source. This is plain wrong since it will inject pseudo-random numbers into the "truly" random source, which in turn will be used to generate more pseudo-random numbers, etc. In this case I think that using rng-tools will make things worse. ...


-1

The only disadvantage of Public key encryption is a key distribution problem: if you need to verify/check your file by multiple software instances, i.e. you're signing an upgrade patch, it's a problem to pass your key untampered to the clients, so forging/MitM will be impossible. If you're about to just encrypt a file - I'd recommend you to use a symmetric ...


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 ...


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 ...


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 ...


0

that's the way i use to do rsa /aes combination client generate a random aes key use the aes key to encrypt the data you need (rsa take longer time and have length limitation, so better use aes to do encrypt) use the public key to encrypt the aes key pass the encrypted data and the aes key encrypted by rsa public key to server when server receive, decrypt ...


0

I'm not a malware author, but I assume it's because it's almost impossible, and it doesn't deliver a benefit. How can the malware 'validate itself' in any meaningful way? Malware is fully exposed to a researcher, who can know whatever the malware knows. It can't contain a secret code that a researcher can't also learn. Any researcher can spoof whatever the ...


-1

Maybe malware authors are lazy, or using strong cryptography would use up too much space. When creating a bot "stub" size is important. In order to remain less suspicious malware is as small as possible, so it can be "bound" with other software. A client to server connection already takes up a lot of the malware's room, adding strong encryption would make ...


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

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 ...


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 ...


0

The question is really about deniable authentication. There might be more than one way for the desiderata to be satisfied in the context given. For example, Alice and Bob could follow this protocol: Alice creates an OpenPGP signing key-pair with a fake name. She sends an encrypted email to Bob with the "public" key attached and instructs him to keep ...


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 ...


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 ...


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 ...


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? ...


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. ...


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: ...


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 ...


0

Any such system worth its salt (sic) will have a time based MAC (or at least an option to add one) for exactly this reason. I can't comment specifically on Apple's service, but I know it's something which, for example, Azure offers for token based access to its cloud storage system... I even wrote a similar mechanism for protecting RTSP streaming commands ...


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 ...


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 ...


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 ...



Top 50 recent answers are included