New answers tagged

1

My question is are they talking about whole javax.crypto package ? No. They are referring to the Crypto provider for javax.crypto. Do I need to remove these all ? No. So long as you did not manually specify to use the Crypto provider, you are fine. Search your code for the string "Crypto" (with a capital C).


0

Actually most implementations of algorithms like BCrypt will generate a salt on their own, from the random source of the operating system. This is the best one can do and there is no need to derrive a salt from other parameters. A salt should be globally unique for each password, so an attacker cannot find any precalculated rainbow-tables, and would have to ...


0

The only other solution than asking for a new password is to save the new hash on next login, setting a flag to know it's upgraded (if needed). This approach is as secure as your current login, and based on your question, will improve it. Changing the current hash is pointless as it will not add entropy.


5

So both of your scenarios rely on the attacker having root access to the phone. In security, it's generally considered that once an attacker has root access, it's game over. That said, there are still interesting things to be said about your question. You asked: Is there a situation where the secure element does offer a clear security benefit to this ...


0

MD5 is broken with regards to creating collisions. That means that it is possible to construct a message M1 in such a way that you can also generate a message M2 so that H(M1) = H(M2). For this the messages M1 and M2 must be pre-constructed in a certain way. So in case of CHAP M1 would be the nonce | password combination. The vulnerabilities of interest to ...


0

As a (nother) addendum to StackzOfZtuff and dr jimbob's answer's the Adi Shamir et al. paper Playing hide and seek with stored keys takes a very different approach, than looking for headers The Shamir approach relies on comparing blocks of data in the complete memory string (i.e. dump the entire contents of memory / disk as a string) and seeing if they ...


2

As an addendum to dr jimbob's answer: There are utilities that look for these patterns and try to extract keys that way. Disclaimer: I have not tried any of these utilities. This post is just a nicer version of the links posted by user "void-star" on HN. (See below.) Whitepapers about the general idea: Adi Shamir and Nicko van Someren, 1998-09-22, ...


2

Assuming a very good hash, use one of Sjoerd's answers. If the hash were very, very bad, however a collision could be calcuated in microseconds. i.e. 256 bit/byte hash alone means nothing unless it was designed properly. A naive hash could be something as simple as a CRC, which was never intended to be secure. Even hashes designed for security purposes ...


4

Let's say we can try 10,000,000,000 SHA-256 hashes per second. For us to find the 256 byte hash, we have to search approximately half the search space, so we need to compute 2^255 hashes. This will take 2^255 / 10,000,000,000 seconds, or about 183587153154040137340770841274555916814545257270485419900205 years. Edit: I screwed up the calculation, because I ...


2

It depends what you mean by "secure" :) CHAP: Client authentication request send its user name to the server Server responds with a nonce Client calculates hash(nonce|password) and send to the server Server verifies the password Cons: All data is transmitted in clear text i.e. it possible for an attacker to eavesdrop and brute-force the hash offline ...


0

Yep, as Lie Ryan says, a forum admin (or any other adversary) cannot edit a signature (or the data that was signed) created using your private key, and have the signature still verify, unless the adversary has your private key too. Having your public key doesn't help. In fact, the entire point of the public key is that you distribute it to everybody; without ...


1

A malicious forum administrator cannot forge the signed text in such a way that it will look like it comes from your key pair. However, a malicious forum administrator can replace both your public key and signed text, with his own public key and signed text, and display it to the person(s) you're communicating with, while still showing you your own public ...


1

Your premise is incorrect, but conceptually I think the problem you're alluding to has been solved by server based password managers using password based key derivation functions (e.g. PBKDF2). Reason your premise isn't right is that symmetric encryption and decryption (e.g. AES) is fast even in JavaScript. These days the cost is low especially when many ...


0

Given that you say this is not a real application, I'll only comment on a couple of points here. The first is an implementation detail that you might have already considered, the second is more of a theoretical "is this worth while?" question. 1. Password changes. It is generally considered good practice to require users to change their password every so ...


0

Using bad, untestable encryption to send secret messages isn't the only risk of this scheme. Like any other computer program, at one level your key becomes an algorithm that tells someone else how to compute it. Even if you were able to come up with an algorithm as good as AES (sorry, you're not), you would need a language to express it so you could share ...


1

It is not a viable encryption method for the technically inclined. 1) All parties that you will give the ciphertext to will need to know the encrypt/decrypt steps. This already ensures that it's not just you who knows the algorithm. 2) You will not be doing this by hand. You will need to turn your algorithm into a software product, that will be distributed ...


8

The flaw in your thinking is here: You have just taken an input, turned it into gibberish in a certain way that only you know how to reverse... Compare that to using a tried and true strong encryption with a long decryption key that only you know what it is. It's possible that your algorithm is equally as secure as the tried and true algorithm, but it ...


3

The algorithm in your example is basically a really simple Caesar Cipher with a fixed key (1), and no, that's definitely not secure. An attacker could determine what algorithm you used rather easily just by analyzing the ciphertext. Other schemes you might come up with could very well have similar vulnerabilities which would let a cryptanalyst reverse ...


0

Found this to the point answer from another forum. These types of cryptographic primitive can be distinguished by the security goals they fulfill (in the simple protocol of "appending to a message"): Integrity: Can the recipient be confident that the message has not been accidentally modified? Authentication: Can the recipient be confident that the ...


1

Assuming you can modify the ./ascii.txt, I would put this text inside: <?php override_function('md5', '$a', 'return "castle";'); And that should work.


1

Firstly, on HTTP there is no way to do this securely. And when you include a TLS connection (a.k.a. HTTPS), why decrypt at the browser? That sounds as possibly the worst place to do so. If confidentiality is really that needed use proper encryption technologies like PGP/GPG and have the user decrypt / encrypt that on his/her/it machine. All you do is ...


4

I see that you accepted gabedwrds solution (which is excellent, by the way), but I wanted to post one potential solution that I have used in the past when doing some interesting pentesting practice. (I am by no means an expert in that field, but I am sometimes a hobbiest.) If you will notice, the script never sets any policy for handling a user abort. By ...


2

Similar to what others have said, PHP has a max memory size. If you put in POST data that was JUST big enough to use ALMOST all of PHP's memory up, then it could conceivably crash when it gets exactly to this line if it ran out of memory: echo 'Wrong or empty password.' This is built on three principles: 1) When sessions are enabled, PHP doesn't flush ...


0

I am assuming when you ask whether WPA-Enterprise is more secure than WPA2, you mean WPA2-PSK (aka WPA-Personal). This is a bit like asking are vegetables healthier than an apple. WPA-Enterprise covers a spectrum of authentication methods (about 100 of them all under the extensible authentication protocol), some very strong, some very weak. WPA2-PSK is a ...


56

Try sending a HEAD request. I'm assuming that with ascii.txt included, the output of the script is just over a nice number like 4096 bytes, a common output_buffering value. Once the script has written output_buffering bytes, it needs to flush the output buffer before continuing. Normally this works fine and the script continues, but if the request type is ...


26

The security flaw isn't in MD5 in this case. And the idea isn't to get if (!isset($_POST['pass']) || md5($_POST['pass'])!='castle') to evaluate in favor of the hacker. The vulnerability appears when you crash the script. The admin privileges are not conditional. No matter what the user gets their permission elevated by setting 1 to $_SESSION['admin_level']. ...


17

I've seen a similar challenge somewhere. Try to send something like 'QNKCDZO' as input. md5('QNKCDZO') is '0e830400451993494058024219903391' (note the 0e prefix in the hash indicating scientific notation of a number) and since the code uses the != operator (instead of the type sensitive !==) PHP (older versions only?) will actually cast it to a number before ...


9

I haven't been able to test in PHP 5.5.9, and what I'm going to propose doesn't work on my PHP 5.6.22 (but I might have made some silly mistake). The only workaround I can fathom is if MD5 returns something that is treated as a number. I've Googled and found something which seems germane.


1

With proper encryption, it could be impossible to know that an encrypted file was originally an executable. Of course, if it gets redistributed in that exact same binary state, antivirus makers could identify a signature to recognize it. Such a distribution system would require a process to be already present on the client computer to decrypt and run the ...


1

There's a tool to detect packed .exes called PEiD . As for good-to-know stuff, check out this reading about how to detect packed .exes based on raw binary data. There are other tools like RDG Packer Detector, but most of them detect specific packers based on signature checking, so practically the same way an anti-virus does.


2

Wow, I am very unimpressed with that PyNaCl doc page that you linked to; Among other things, they don't explain what this nonce is being used for internally. That makes it hard to answer your question. That said, the example code has some comments that give some hints about what it's doing inside, so I think we can puzzle through it. Usually, a "nonce" is a ...


0

It doesn't happen anywhere... because OSI doesn't actually happen anywhere. OSI was always a theoretical model, and TCP/IP does not use OSI. Besides, arguing about "which layer" something happens at is pointless; it is much more important to understand how the layers interact, and what kind of protection would work best at each layer. E.g you could get ...


3

It seems surprising because crypto libraries are available on all (major) platforms. But it sounds often simpler than it is. For example accessing the Crypto API on Windows takes a lot of additional code to do it properly. But the amount of malware authors being very familiar with cryptography is rather small. Therefore they tend to focus on functionality ...


6

Encryption can happen at any of the levels of the OSI model. TLS happens at something like the session or transport level. Quantum Crytography isn't exactly encryption, but would be at the physical level. PGP in an email would be at the application level. Remember that the OSI model is just one model, and largely represents an idea of separation of ...


1

It depends on the protocol used. TLS is used for application level end-to-end encryption so it is somewhere at levels 5..7 (the distinction between these levels is blurry). Protocols like IPSec or OpenVPN instead work at the level of IP protocol, i.e. network layer which is layer 3. But there are also VPN technologies which do a VPN at the data link layer, i....


4

In my personal opinion, the layers are a bit fuzzy. In my mind there's physical, ethernet, IP, TCP, TLS, and finally some protocol like http. Or physical, ethernet, IP and finally ICMP, for example. Which OSI layers those are exactly? Who cares. TLS is called Transport Layer Security, but in my mind the transport layer is TCP/UDP. Googling, most people ...


1

The most secure way to store a private key is to generate it on a smart card or in an HSM. Is that an option? The smart card or HSM can still be used to encrypt and decrypt by whoever has access, but it won't give up the key. You can put the public key wherever you want.


0

If your app running as the user can access a chunk of data, any process running as that user can access it too. As you saw in your investigation of option 2, determined programs will be able to find the data if it's stored without additional encryption. If you implement some encryption, as in option 1, somebody could reverse engineer your application to ...


0

When you configure an interface to use CHAP, you must assign an access profile to the interface. When an interface receives CHAP challenges and responses, the access profile in the packet is used to look up the shared secret, as defined in RFC 1994. If no matching access profile is found for the CHAP challenge that was received by the interface, the ...


1

I would perfer Nr1 due to simplicity, but take Nr2 if: (a) In your case, Encryption and Decryption really -is- slow for some reason. So slow that its a problem for Usability. Perhaps massive amounts of Data or user machines with very bad processing capacity. (b) It was not a typo in Option 1 that they use a third party key. In my opinion they could make ...


0

The shared secret key is symmetric, so there's no public and private here. The same key is used to encrypt and decrypt messages. That's why it needs to be encrypted before it is sent to the partner, using his public key. Only your partner can decrypt your encrypted symmetric key because only him has the private key that goes with this his public key, so your ...


1

The phrase "bitwise cipher" is most likely XOR'ing the base64 of the plaintext with a key of the same length. This is the most basic kind of symmetric cipher. Try XOR'ing the base64 of the plaintext with the ciphertext they give you to get the "key". Then XOR this key with the challenge text to decrypt it. And yes, I am aware this is an old question and ...


1

FWIW, NIST draft on post quantum crypto is recommending 256. http://csrc.nist.gov/publications/drafts/nistir-8105/nistir_8105_draft.pdf


1

Before the details : Telegram's server side code is not available as open source and hence can't be reviewed. Telegram uses Diffe-Hellman for key exchange and AES-IGE encryption. The basic principle of understanding in DH key exchange is that No entity can effectively intercept the key generation while simultaneously making sure that the parties ...


1

WhatsApp derives the QR code (and the numerical representation) from the user identifier and the 32-byte public Identity Key of both parties. I guess that some deterministic algorithm decides, witch of the two identifiers comes first (e.g. they could be sorted lexically). This allows both clients to display the same image and numerical representation, ...


1

KW allows you to establish a long term secret but still use a different CEK for each message, this is important for some use cases, but not all. In the case of using JWE to send a single message to multiple recipients who all have different long term keys, this is essential as you need to wrap the CEK multiple times once for each recipient. JWE supports a ...


0

This is fairly easy to understand. Simply symmetric encryption use single key for encryption and decryption while asymmetric use different keys (4 different keys). Main disadvantage of symmetric key is the damage, if someone get your key. He can read your messages(sent/receive). Because you use the same “compromised key” for encryption and decryption.(Read ...


1

The main disadvantage of using a shared key in encryption is that you cannot use it to ensure non-repudiation. If you got a message and you are able to decipher it, there is no proof that the sender did encrypt it, because one can still argue you encrypted it yourself.


2

The disadvantage of symmetric encryption Symmetric encryption always use the same key for encryption and decryption - that is the very definition of it. That has one major downside. If the person doing the encryption and the decryption are not the same, they have to somehow securely share the key. If A generates a random key and encrypts a message for B ...



Top 50 recent answers are included