Tag Info

New answers tagged

0

It's highly unlikely that this is a significant component of the threat model for most error reporting systems. It's generally going to be too hard to craft fake data that will both appear to be real data to the system, and achieve some arbitrary malicious goal to boot. It would be a lot of work for a dubious gain. That said, there are ways you can ...


1

In addition to the technique Enos mentions, another common technique is to use hashes. For many testing requirements hashes will be sufficient. Couple of gotchas, though: If the space isn't big enough, collisions could cause problems If you have logic that does something like matching account types by the first 4 digits being 0123, then hashing will fail ...


1

If you must absolutely use production data in DEV, you may produce a table matching actual account IDs with random ones, then destroy or adequately protect the table after transferring data. REAL ID | FAKE ID -------------------- 0000001 | 3287638 0000002 | 5917382 etc. Beware DEV data may include other information connected to the account ...


3

You should be worrying about secure storage of the AES key, not about breaking up the data. If the key is compromised, it really won't make any difference what you've done with the data because Kerckhoffs's principle. Edited to add: Most especially, you must not store the AES key in the same database that holds the encrypted data because a database ...


1

May I suggest that you rethink your approach to this problem. Where are you storing the data? If it's in a database most databases have the ability to encrypt data at rest fairly securely. Does the data need to move over an insecure channel? Look into the HTTPS or secure FTP. Don't mess with crypto unless you absolutely have too. It's extremely easy to ...


25

You are doing it wrong. Not in the splitting or whatever; but in the thinking. AES encryption, if done properly, won't be "cracked". AES is the most robust piece in your system; this is the last part of it that you should be worrying about. What AES encryption provides is a very specific functionality: using a given key K, it transforms a piece of data (the ...


0

Depending on where you're at, I'd say this is a great high school project. The ipsec + dnssec + pki + tls/ssl route is very much a protocol based facet of this exercise. Maybe you'd like to bring up the physical security aspect of things as well. For example you bring up the location of the endpoints as a mitigating factor. After all, fips level skiffs for ...


0

The answer (at least for my work) is IPsec host to site or host to host with PKI authentication and protection of the private keys in hardware.


0

In IPSec transport mode, only the IP payload is encrypted, and the original IP headers are left intact. It also allows devices on the public network to see the final source and destination of the packet. With this capability, you can enable special processing in the intermediate network based on the information in the IP header. However, the ...


-1

The red flag mentioned by Mark is not quite an argument. If you read their technical overview to the end you will notice that all keys can be stored locally and no internet connection is required. Nevertheless it is closed source. So no, you can not trust them.


1

If you can require that the ranges are block-aligned, the disk encryption modes (LRW, XEX, XTS, CTR, etc.) seem ideal for your purposes. ECB mode also works with block-aligned ranges, but is, well, ECB mode. If you need byte-level alignment, the only mode that looks promising is OFB mode: you compute a keystream that includes the range you want to decrypt, ...


0

From Cisco: http://www.ciscopress.com/articles/article.asp?p=25477 Tunnel mode is most commonly used between gateways, or at an end-station to a gateway, the gateway acting as a proxy for the hosts behind it. Transport mode is used between end-stations or between an end-station and a gateway, if the gateway is being treated as a host—for ...


1

There's a lot of good general security practice information in the other answers, but as I've just been researching for myself the implementation of security in the HomePlug AV spec (used by the devices you mentioned, and many others), I thought I'd add a little more specific info not covered yet. First, there's no such thing as unencrypted data transfer ...


4

Based on a google search of your hash it's a Dahua hash.Luckily for you it looks like it has some vulnerabilities www.exploit-db.com/download/29673/ I don't know if they fixed vulnerability and I don't really know much about CCTV systems.If that fails you could try bruteforcing the hash.


0

The risk is you have one key on multiple servers (from what I understand). If it's not encrypted and someone who shouldn't have it got it, then you have a problem. That being said, AES is very safe if used with randomized IVs.


3

Yes, it's in scope. There's actually a pretty thorough and explicit guide from the PCI Security Standards Council (the DSS people) to your exact question here: Information Supplement: Protecting Telephone-based Payment Card Data Which makes reasonably clear statements like this about card numbers: Call centers will need to ensure that PAN data is ...


0

In order to provide a service like (and actually have it be commercially used) there needs to be participation between multiple parties. The only way I can see this working is if there is a centralized key server that would act as the "Bob" and "Alice" of the equation. If you want to secure yourself from metadata revealing location and any forensic pattern ...


1

Skype is a modified P2P network. You have no guarantee that your traffic is going to them, so a sniffer wouldn't work the way you'd expect. However, you can resolve the person's username to their ip address with a tool like this while they are online. So if you can get their username from the Skype number, or the email address associated with the number (to ...


1

Yes it is possible but unnecessary in your case. People often use VMs to isolate potentially malicious applications from their main host and to have some sort of rewind button to restore the VM to a previous state in case something goes wrong in there, but looks like that's not what you want to do. To defeat forensics all you need is full disk encryption ...


0

FYI, with minor changes to tpm-luks, I got it working with our application to secure the root partition's LUK key in TPM NVRAM. The scripts work like a charm. It's easy if it's not a root partition but maybe some other partition or file. I tied the key into NVRAM based on PCRs 0 through 9 and also 12 and 13. Be aware your BIOS should comply with NIST ...


-3

In asymmetric encryption with public key cryptography, there is an exchange of public keys which could be intercepted by a man-in-the-middle. That is a major weakness, which symmetric encryption doesn't have. Since the US government is doing mass-surveillance, there's a real possibility that MIM is commonplace. Using predetermined keys with symmetric ...


0

Although this part is probably obvious, I did not see this stated in any of the other answers. All the information you enter into the form can be potentially obtained (depending on how the form is coded) at the very least by the person who receives the form. This is why it is good to use different passwords for different sites (e.g. the owner of one site ...


0

could you recommend what I should do to keep someone in computer forensics from finding any deleted files or files for that matter? Securely delete files, and erase over the empty space on your hard disk with a three-pass algorithm. There's a great guide for that here, on AskUbuntu. Technically you can recover stuff that has been passed with less than ...


4

Cryptographically secure voting is difficult because voting encompasses so much. Let's take, for example, vote-buying or coercion. Imagine a system where I can vote, and can verify that my vote was tallied correctly. Now I can provide that proof to a third party who purchased my vote to claim renumeration for that vote. If the voter cannot verify their ...


12

No, it isn't safe because you expose (in your program) a key which should be secret. Your proposal is based on symmetric key cryptography, where both ends of the communication channel need a copy of the same key. Symmetric key cryptography is effective only when both ends of the channel are secure. As others have pointed out, a key embedded in a program ...


4

No, this is not a secure alternative. It is entirely possible that a hard-coded key could be discovered, which would leave you with application traffic that is essentially unencrypted. So, if you feel the data is not sensitive enough to secure, don't bother encrypting it at all. Deliver it over HTTP. If, however, there is any reason to secure it, do ...


1

Unluckily, although PGP is awesome in theory, the "real world" benefits of PGP are quite limited, if existent. If PGP was the default that everybody uses, it would rock. TLS gives you (ignoring the possibility of exploits) a secure connection to your mail server. You have the guarantee that the server you talk to is really your mail server, and that nobody ...


0

Let's start with having a look on what RFC 4880, OpenPGP considers important in the introduction (highlighting added by me): This document provides information on the message-exchange packet formats used by OpenPGP to provide encryption, decryption, signing, and key management functions. What do we need for the individual tasks? Key management ...


1

If you connect and submit a form using your VPN connection, the site will get your VPN address, not your main IP address. But with a little javascript file they can get a lot of information about you: Browser type, version and revision All plugins installed You operational system Screen size and depth If they succesfully exploit DNS Leak, or put Flash ...


1

Submitting a form is no different from browsing a site. It is, in fact, submitted by the exact same or very similar kind of request to the one used to get the website in the first place.


9

HTTPS only protects your email between you and Google. From then on it is transferred unencrypted. That means your email can be read by: Google (and they admit that they read it!) any routers between Google and the mail service of the receiver the receivers mailserver when the receiver isn't also using https, any router between their mailserver and them. ...


0

Generally on a computer, software encryption often runs on shared architecture such as your computers CPU. True hardware encryption would run on something like a Secure Cryptoprocessor or similar dedicated chipset. This can help isolate secure procedures from the rest of the system and often have architecture to very quickly run the needed calculations. ...


3

You could try to put the file on a filesystem which is mounted as read-only. That would at least thwart any attack which uses the normal attack path via file access over the operating system. However, when the malware doesn't use the normal filesystem and does instead attack the raw hard drive devices, this will not help you. The best way to restore a file ...


1

Ultimately, there is no difference: both "type" of encryption will end up running some software on top of some hardware so this is mostly a marketing argument. How an encryption stack works exactly depends, of course, from case to case and it is very important to review the details. For instance, some hard drive will implement some encryption layer in the ...


0

Hardware based encryption has several advantages: Speed - hardware encryption works much more faster than software one. Independence - it's independent from host system - OS, drivers, etc. Separate processor for number generation is also big plus. Security - More secure against malware, brute force attacks, cold boot attack, etc.


1

Any data can be encrypted; there's nothing you can do to make arbitrary data unencryptable.* As for "a honeypot with a file to somehow reveal the key needed to decrypt the rest of the files," that's what's called a chosen-plaintext attack. Some encryption methods are susceptible to it, but for that reason they're not generally used in the real world. ...


6

In short, PGP protects the contents of the email, both in-flight and at rest; TLS protects the communication channel while the message is transiting a network. PGP vouches for a person and an email address; TLS vouches for a server (and optionally a client).


24

There is more at risk in using SSL/TLS than potential 0-days, because there are already known attacks that can circumvent TLS. Moxie Marlinspike has been giving Def Con presentations on it since at least Def Con 17. One of the most notable tools is sslstrip, created by Marlinspike. TLS also requires a Certificate Authority trust model, which gives ...


54

SSL/TLS protects the email from tampering or eavesdropping as it transits between your computer and Google's server, and possibly during further relays to eventual recipient. And that's all it does. PGP does far more. If you're sending a signed email, the recipient can verify that the email was sent by you, and that it was not tampered with at any point ...


12

non-repudiation -- no one can forge your private key signature of a message, encryption at rest -- the message is encrypted not just in transit, but at rest as well. all of the benefits of mail over SSL/TLS sans a lot of the problems (e.g. Heart Bleed and POODLE) Just to name three.


3

The biggest difficulty you will have in building this system is not a technical one, but more political, and legal. You are going to be targeted by every government in the world. Government's will be your biggest threat, and I cannot see where you could possibly get proper hosting without some form of “backdoor/channel” for government agencies. For example, ...


1

Perhaps you want pairing-based cryptography (a subset of ID-based encryption) to solve the keying and key storage problems.


2

From what I can find on Sophos website, it looks like the encryption keys and revelant certificates are stored on a mssql database which holds the information. The SafeGuard Enterprise Database(s) hold all relevant data such as keys/certificates, information about users and computers, events and policy settings. The database(s) need to be accessed ...


2

A certificate issued to *.example.com is a so-called "Wildcard Certificate". It is valid for all subdomains of example.com like www.example.com, mail.example.com, forum.example.com etc.. It would not be valid for the main domain (just example.com) or on any nested subdomains like login.forum.example.com. However, additional domains can be added to a ...


1

I think you have a fair point here. In the current thread model the only thing you should consider is where and HOW the keys are stored. Storing the keys -as long as they are encrypted- on the server and transferring them ONLY via TLS shouldn't be an issue. You should research how the big players in this area did it before, like the services you ...


0

You are certainly on the right track but it is possible that you're making it just a bit more complicated than you need to. You have correctly identified that a symmetric encryption system creates the significant issue of the decryption key being present on the system. If you choose to generate public/private keys for each piece of data, you may be making ...


8

The biggest point you're missing is a threat model. You've got a bullet-point list of security decisions you've made (some of them rather questionable), but you don't have any idea who you're defending against or what their capabilities (both technical and legal) are. The appropriate precautions for defending against your little brother are very different ...


5

If the attacker knows for sure that the (character space size) ^ (password length) is greater than 2 ^ (AES key length), then, yes, it's a better idea for the attacker to brute-force the AES key. Given such an assumption of the attacker's knowledge, it's a mathematical fact that the search size for the AES key will be smaller. Such an assumption of attacker ...


8

The risk is that an attacker can forge data. In other words, they can come up with their own ciphertext and then figure out the expected HMAC to make your system accept the input as valid. The whole point of the HMAC is that only you as the owner of the key can “sign” data. However, if the application leaks information about the expected HMAC of the input, ...


18

It allows for the potential of an existential forgery. An attacker can create a valid HMAC for a chosen message without knowing the HMAC key. Basically, the way the attack works is this: The attacker sends a message, and an HMAC (really just a sequences of bytes the same length as the HMAC) and times the response from the decryption system. The ...



Top 50 recent answers are included