New answers tagged

1

There is a better method today if you are using android. The developer tools offer a way to sniff Bluetooth packets into a log that can be opened in Wireshark. Go to Developer Options on your phone and enable hcidump. See this blog post for more details


1

If your main objective is to ensure integrity and authenticity, and not confidentiality, it sounds like what you want is not encryption, but message authentication (symmetric, like HMAC) or a digital signature (asymmetric, like RSA). Since you mention third parties, it's likely that signing with an asymmetric system should be used, since with a symmetric ...


0

Is is difficult to to implement either? No not really, as long as you use a vetted and verified implemented library. AES is much faster than RSA, but as you only sign a hash the amount of data operated on should not be much of a concern. RSA (is that is the assym. alogrithm you wish to use) is 2048 (see) and 256 for AES. With AES you would probably want to ...


1

Linux uses TSC by default for its clock source due to its lower overhead, and only uses HPET as the fallback. The kernel gathers entropy from interrupt timing intervals, using the RDTSC instruction on x86 processors. Unless you do not have TSC support, then I do not believe disabling HPET will influence your entropy collection at all. Only on certain ...


2

What you need to do is encrypt the file(s) before uploading it to the cloud provider, and decrypt them on download. Assumptions You do not want to cloud provider to by able to read (decrypt) these files. You would like something simple to implement Do This Use a symmetric algorithm to encrypt the files. The most common secure algorthm is AES There ...


-1

AES is available in any crypto library. Use AES. Or better than that, use a blackbox library like NaCl or libsodium with the defaults, which was designed by a top-notch cryptographer, meaning you don't have to worry about screwing up the implementation which you are indeed quite likely to do if you try and implement this yourself.


-1

The one that fulfills your requirements. If you just want to upload and download it, don't encrypt it. If you want to encrypt it because encryption sounds so cool, just XOR it with 01010101b. If you want to encrypt it to be secure, define what secure means for you. Do you want to prevent the cloud provider from automatically analyzing your file? Do you ...


0

Your need is just for storing the file in the cloud and assuming that the key will always be with you and only you. Here is the list of algorithms that you can use: Triple DES RSA Blowfish Twofish AES You can encrypt with anyone of these and upload them to cloud and for decryption, you will only be having the key.


2

One of the biggest issues that you face is not the algorithms you choose, but how you implement using them. There are many good algorithms for various purposes, and virtually any of them, improperly applied, can result in a disastrously broken cryptosystem. This is one of the reasons people offer advice like "use libsodium" because libraries like ...


1

To answer the question you specifically asked...No, hashing the Int32 value to use as the salt is not significantly stronger than using the Int32 directly. It would, as you already suspect, be more obscurity than security. As Martin pointed out in his answer, the key property of a salt is that it be globally unique. You do not get this property with ...


0

Although I very much like @thomas-pornin's answer, I think there's a problem with the first assumption that must be called out. Laundauer's Principle only applies to irreversible operations. Contrary to what some may assume, reversible computing is already achievable. The operations are common in quantum computers and homomorphic encryption systems. ...


3

In cryptography you don't have just one opponent who attacks you in the way you expect him to. This is what makes it hard to reason about, because you have to think of absolutely EVERYTHING. But really, nobody can possibly outsmart every possible opponent. The best we can do is utilize our common knowledge and existing research as much as possible and take ...


4

Your question as originally posted is not very clear. If you require Public Key / Asymmetric Encryption algorithm, the safe/simple choice is to use RSA with a 2048 or better key size. If you require a plain Symmetric encryption algorithm, a good choice is AES-256. The keys should be created from a Cryptographically Secure random number generator. For ...


1

As an addon to Trey's answer: I use the string ALL:COMPLEMENTOFALL when want I every cipher suite. I use the -V (upper case V) option to make OpenSSL output the hex-IDs of the cipher suites. Note: OpenSSL is not authoritative for answering these questions. IANA is. (But I couldn't get their CSV file parsed nicely.) $ ./openssl version OpenSSL 1.1.0-...


2

1.) See openssl output below and excellent Wikipedia page below 2.) No not all of them, see the tables at the URL below. 3.) No not all of them, see the tables at the URL below. https://en.wikipedia.org/wiki/Transport_Layer_Security openssl ciphers -v 'ALL:!aNULL' ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ...


0

I do not believe the Diffie-Hellman (DH) choice is legacy, which means obsolete and superseded, it just is not used very often. In my opinion, that's because it's not the first one in the dropdown when choosing your Cryptographic Service Provider when making a certificate request. If someone is actually doing their homework when they make their choice, ...


4

I was wondering whether a CA has different private keys to sign certificates with? A CA will usually have a number of Intermediate Keys for use in signing customers' certificates. These Intermediate Keys are in turn signed by the CA's Root Key, which should be stored "offline" and only used rarely to sign those Intermediate Keys. The matching Root ...


0

What we consider to be a Certificate Authority is represented by a "Trusted Root Certificate" which is a self-signed certificate that is delivered by secure means (most often during the OS or browser installation process.) Typically a single Certificate Authority issues only one Trusted Root certificate, but not always. A company that operates as a CA is ...


3

I was wondering whether a CA has different private keys to sign certificates with? In general, no. There is one key pair - and thus private key - per certificate. Certificates can be rolled over to use a new key pair of course. Furthermore, in general, a CA manages multiple certificates for different purposes. The CA may also have different certificates ...


0

You can look the following questions about difficulties in generating your own DH key exhcange parameters and also using the standard DH group parameters: Is it safer to generate your own Diffie-Hellman primes or to use those defined in RFC 3526? and Where do I get prime numbers for Diffie-Hellman? Can I use them twice? For plain Diffie-Hellman, what you ...


0

The two-thirds number you refer to is specific to VPN servers using IPsec. I would wager to guess this is a result of Sys Admins and Security Individuals not taking the time to modify any more of the default settings in their server than they absolutely need to during configuration. Or, it very well could be an issue with the specific implementation of ...


0

I just wanted to append my thoughts to this since I've been recently going through the same thing. All my attempts of trying to get ECDHE with SunEC have been pretty unsuccessful, so I'd strongly recommend just using Bouncy Castle. You just add the provider jar to your JRE/JDK ext folders and modify your security providers in your java security file and ...


3

Passwords are concerned with system access. They are used to verify that you are who you say you are (example: logging into email), or at least that you are someone that is allowed to access the resource you are trying to access (example: a code to open a door). The important thing about passwords is that they are fed into a system, so extra measures like ...


0

Early forms of cryptography were based on secret encryption algorithms, but it soon became apparent that this was a terribly bad idea. If you suspect the algorithm is learned by the enemy then they can potentially decode everything and you have to throw it all away and start again. And algorithms are hard to think up. A better idea is to use a key. In a ...


1

I am not sure I can answer this question perfectly, but I'll try. First off, think of symmetric algorithms. One such algorithm is a method to encipher(encrypt) a message, and must be completed with a key, in order to tell the algorithm exactly how to encipher said message. The enciphered message is called cipher-text. The recipient of the cipher-text must ...


0

To my knowledge, a key is a password used to decrypt a message. The Key is built out of a Password Derivation function. The function (i.e. PBKDF2, or a repetetive SHA-256) is designed to take a notable amount of load. (i.e. 250ms) The derived Key is more difficult to guess than the original password (i.e. defend against a rented cluster trying to brute-...


0

The real answer is that SSL certificates in their current form are comically hard to use. They are so unusable that it threatens the security of certificates, as people take shortcuts to just get stuff done. I say this as somebody who routinely deals with 2-way SSL (PKI certs), the TLS stack incompatibilities that are created by the complexity of the spec, ...


3

How do software companies ensure that their product or app can only run in a given number of bare-metal or VM instances? They don't! Software companies start with some half-a**ed technologies that are incomplete solutions. These are then watered down so they don't break the user model too badly. In the end, the only thing that software licensing does is ...


0

No, this is not possible. If you change a single bit in a block that is put through the cipher then all bits change with a certainty of 50% due to the avalanche effect. So even though only one bit will be changed in the next block, the current block will still completely change. Differently said, AES is a block cipher and a keyed block cipher is a pseudo ...


2

Yes, why not. Key generation (including key generation for ECDH) and private key operations are relatively efficient compared to other cryptosystems such as RSA. There are some things to keep in mind: standard ECC operations such as ECDSA do require a good random number generator to be present; the small key size makes it relatively simple to use quantum ...


4

One system I've seen is to use dynamic license codes. Each time the software is run, it connects back to the vendor's server. It submits the current license code, and is issued a new one. The old license code is invalidated. If the VM is cloned, then only one clone will have the new license code. Drawbacks with this system: Internet access is required to ...


3

Hushmail does something like this (or used to). The private key was stored locally and the website would send a Java applet to handle encryption/decryption and signing operations. It would protect you against the vector you describe... but... the whole model of a web application handling PGP has serious limitations. When you log on to the compromised ...


2

If you want information about the estimated strength of the ciphers, I still recommend the 2013 ENISA report. I don't know of any constantly updated list, but the only way the assumptions in that report can change is if some cipher is broken (in the cryptographic sense, not necessary relevant in practice), and that will be widely reported, if it is made ...


3

Many countries publish Security standards for cipher suited. In US, you can rely on pci dss standard, fips 140-2, ANSI, EAL, etc. In France we have the RGS which indicate the algorithms and key length which can be trusted and how many time we can rely on. I guess every industrialized country has the same standard. I personally choose to follow this ...


0

As an FYI, if it is Cryptowall and not a variant, you could use most "unerase" like tools to recover your data if you perform the unerase as soon as possible. (This does not apply to anything outside of Cryptowall). The good, bad, and ugliness of determining what you have lies in the methods that AV companies use in their naming conventions. Too often ...


3

Most vendors using SSL/TLS commonly use OpenSSL who keeps a detailed record of vulnerabilities associated with SSL/TLS. Subscribing to security sites like Bugtraq will keep you in the loop regarding disclosed (known) vulnerabilities associated with OpenSSL and may tell you about the other SSL libraries as well. You would also want to subscribe to other ...


2

Most ransomware use strong encryption algorithms, which means that you will have a hard time trying to decrypt the encrypted files without the corresponding decryption key. The malware uses an AES key to encrypt files. The AES key for decryption is written in the files encrypted by the malware. However, this key is encrypted with an RSA public key embedded ...


0

This is impossible as @mr-e said: CBC works by XORing the plaintext with the IV / previous ciphertext before encryption. Without access to the ciphertext you cannot alter the rounds.


1

I have contacted the authors and they were very helpful. The original quote says it all: The book is about randomized algorithms that act on data sets. You can always view these as deterministic algorithms, which take two inputs -- the data set, and also a string of random bits. The definition of differential privacy has a probability operator, and ...


1

McNerdHair is correct to require you to use an authenticated mode. There are more options than GCM mode though: GCM mode is fast. It is sometimes called a 1.5 pass authenticated mode because of the fast GMAC calculation. It is standardized by NIST. CCM mode is another NIST certified mode specifically created for packet encryption, i.e. transport mode ...



Top 50 recent answers are included