New around here? Register your SA Forums Account here!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
RISCy Business
Jun 17, 2015

bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork
Fun Shoe
:siren:THREAD MASCOT:siren:


quote:

Don't roll your own crypto.

Don't invent your own encryption algorithm or protocol; that is extremely error-prone. As Bruce Schneier likes to say,

"Anyone can invent an encryption algorithm they themselves can't break; it's much harder to invent one that no one else can break".

Crypto algorithms are very intricate and need intensive vetting to be sure they are secure; if you invent your own, you won't get that, and it's very easy to end up with something insecure without realizing it.

Instead, use a standard cryptographic algorithm and protocol. Odds are that someone else has encountered your problem before and designed an appropriate algorithm for that purpose.

Your best case is to use a high-level well-vetted scheme: for communication security, use TLS (or SSL); for data at rest, use GPG (or PGP). If you can't do that, use a high-level crypto library, like cryptlib, GPGME, Keyczar, or NaCL, instead of a low-level one, like OpenSSL, CryptoAPI, JCE, etc.. Thanks to Nate Lawson for this suggestion.

recommended resources:
SecLists.Org Security Mailing List Archive
attrition.org
r/netsec
r/crypto

conferences/gatherings:
BSides (check for one local to you!)
Black Hat
DEF CON
ShmooCon

recent news:
HardenedBSD ends their call for donations on a successful note
Let's Encrypt begins closed beta
CISA is revealed to not contain Senator Whitehouse's CFAA amendment

more resources:
VulnHub - Vulnerable By Design
OverTheWire
SmashTheStack

RISCy Business fucked around with this message at 14:52 on Dec 18, 2015

Adbot
ADBOT LOVES YOU

RISCy Business
Jun 17, 2015

bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork
Fun Shoe
reserved just in case

RISCy Business
Jun 17, 2015

bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork
Fun Shoe
on this topic, if anyone needs/wants an invite to keybase, i have 5 left- send me a pm or an email (root[a]reverie.pw) with your email address and i'll get you squared away

RISCy Business
Jun 17, 2015

bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork
Fun Shoe
hey, remember Linux.Encoder.1? turns out it sucks

http://labs.bitdefender.com/2015/11/linux-ransomware-debut-fails-on-predictable-encryption-key/

quote:

We mentioned that the AES key is generated locally on the victim’s computer. We looked into the way the key and initialization vector are generated by reverse-engineering the Linux.Encoder.1 sample in our lab. We realized that, rather than generating secure random keys and IVs, the sample would derive these two pieces of information from the libc rand() function seeded with the current system timestamp at the moment of encryption. This information can be easily retrieved by looking at the file’s timestamp. This is a huge design flaw that allows retrieval of the AES key without having to decrypt it with the RSA public key sold by the Trojan’s operator(s).

:effort:

mindphlux
Jan 8, 2004

by R. Guyovich
hmmm wow I just hmmmmmm I mean go on wow this is so interesting tell me more

RISCy Business
Jun 17, 2015

bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork
Fun Shoe

mindphlux posted:

hmmm wow I just hmmmmmm I mean go on wow this is so interesting tell me more

i love watching literal mongoloids post so thank you for this opportunity

RISCy Business
Jun 17, 2015

bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork
Fun Shoe
some shady poo poo coming out of the marketing world (again):

Beware of ads that use inaudible sound to link your phone, TV, tablet, and PC

quote:

Cross-device tracking can also be performed through the use of ultrasonic inaudible sound beacons. Compared to probabilistic tracking through browser fingerprinting, the use of audio beacons is a more accurate way to track users across devices. The industry leader of cross-device tracking using audio beacons is SilverPush. When a user encounters a SilverPush advertiser on the web, the advertiser drops a cookie on the computer while also playing an ultrasonic audio through the use of the speakers on the computer or device. The inaudible code is recognized and received on the other smart device by the software development kit installed on it. SilverPush also embeds audio beacon signals into TV commercials which are "picked up silently by an app installed on a [device] (unknown to the user)." The audio beacon enables companies like SilverPush to know which ads the user saw, how long the user watched the ad before changing the channel, which kind of smart devices the individual uses, along with other information that adds to the profile of each user that is linked across devices.

The user is unaware of the audio beacon, but if a smart device has an app on it that uses the SilverPush software development kit, the software on the app will be listening for the audio beacon and once the beacon is detected, devices are immediately recognized as being used by the same individual. SilverPush states that the company is not listening in the background to all of the noises occurring in proximity to the device. The only factor that hinders the receipt of an audio beacon by a device is distance and there is no way for the user to opt-out of this form of cross-device tracking. SilverPush’s company policy is to not "divulge the names of the apps the technology is embedded," meaning that users have no knowledge of which apps are using this technology and no way to opt-out of this practice. As of April of 2015, SilverPush’s software is used by 67 apps and the company monitors 18 million smartphones.

some of the stuff that can be transmitted:



it can also trigger a recording as seen here

code:
SilverPush Beacon Demo App_v1.0.3.src/com/silverpush/democrossdevice/m.java:16:  private AudioRecord h;
SilverPush Beacon Demo App_v1.0.3.src/com/silverpush/democrossdevice/m.java:35:      this.h = new AudioRecord(this.f, this.g, this.d, this.e, this.j);
SilverPush Beacon Demo App_v1.0.3.src/com/silverpush/democrossdevice/n.java:7:  implements AudioRecord.OnRecordPositionUpdateListener
SilverPush Beacon Demo App_v1.0.3.src/com/silverpush/democrossdevice/n.java:13:  public void onMarkerReached(AudioRecord paramAudioRecord)
SilverPush Beacon Demo App_v1.0.3.src/com/silverpush/democrossdevice/n.java:17:  public void onPeriodicNotification(AudioRecord paramAudioRecord)
SilverPush Beacon Demo App_v1.0.3.src/com/silverpush/democrossdevice/p.java:9:    int i = AudioRecord.getMinBufferSize(44100, 16, 2);
SilverPush Beacon Demo App_v1.0.3.src/com/silverpush/democrossdevice/p.java:23:          AudioRecord localAudioRecord = new AudioRecord(1, 44100, 16, 2, m);
SilverPush Beacon Demo App_v1.0.3.src/com/silverpush/democrossdevice/p.java:24:          if (localAudioRecord.getState() != 1)
SilverPush Beacon Demo App_v1.0.3.src/com/silverpush/democrossdevice/p.java:26:          localAudioRecord.release();
there is a git repo [HERE] run by d0tslash on twitter with tons of information including APKs if you care or want to help

RISCy Business fucked around with this message at 15:56 on Nov 17, 2015

Stanley Pain
Jun 16, 2001

by Fluffdaddy
How is it going to record that data on any of your devices though? You'd have to be stupid to install their software on your phone or am I missing something here and they're exploiting something?


Ah I see, some apps might be using their SDK. I wonder how long before we get someone writing a program that can check for the SDK being used. I'm sure it has to have some form of normalized API calls.

RISCy Business
Jun 17, 2015

bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork bork
Fun Shoe

Stanley Pain posted:

How is it going to record that data on any of your devices though? You'd have to be stupid to install their software on your phone or am I missing something here and they're exploiting something?


Ah I see, some apps might be using their SDK. I wonder how long before we get someone writing a program that can check for the SDK being used. I'm sure it has to have some form of normalized API calls.

yeah, it doesn't have to be THEIR app, just one utilizing their SDK. and what is pulled and sent is up to the whim of whoever runs that app. it would be possible to sniff out calls using wireshark if you're curious and think you may have such an app, since it seems a lot of them[citation needed] use the same url schema, you could use:

http.request.method=="POST" and http.request.uri contains "/oapi/getAd"

YouTuber
Jul 31, 2004

by FactsAreUseless
Is this the thread where I can learn to be Anonymus and pwn noobs over the internet ?

Antillie
Mar 14, 2015

I thought this was a thread were we could discuss whether or not it should be best practice to disable TLS 1.0 on web servers that also support TLS_FALLBACK_SCSV. Or maybe what a good lifetime value would be for a HTTP Strict Transport Security header and the pros and cons of including the preload option in said header. But for some reason we are talking about a new form of advertising tracking that is supposedly only being used in India.

DeaconBlues
Nov 8, 2011
Nice thread topic!

I'd like an effective and relatively simple way of turning a short password into a hash type string to use as a passphrase for AES encryption please.

In the past I've used the MD5 of a simple string (such as a car license plate) and I know that people here will poo poo brix that I used something as insecure as MD5 but, hey, it's better than the original password!

I looked at PBKDF2, which seems ideal for stretching a simple password into an indecipherable string and then found out that there are better alternatives, such as bcrypt which has more expensive overheads if someone attempted to reverse the data.

The problem with bcrypt (and scrypt, I believe) is that they are geared toward storing passwords for web services and produce a more complicated output than I desire. I just wanna derive an encryption key from a simple string.

PBKDF2 looks the sort of thing I'm after but there doesn't seem to be a standardized implementation of it. I want to encrypt something with the knowledge that I can decrypt the file in maybe 5 years time, possibly using a different OS (it will still be Linux based, though) or platform. At least MD5 and SHA256 are both standardized algo's and produce the same result over all platforms.

What do you guys use to manually scramble your passwords?
Please don't suggest keepass2: I'm looking for simplicity. Thanks.

Theris
Oct 9, 2007

DeaconBlues posted:

In the past I've used the MD5 of a simple string (such as a car license plate) and I know that people here will poo poo brix that I used something as insecure as MD5 but, hey, it's better than the original password!

What's wrong with MD5? I mean, it turns my street's name (why are you using license plate numbers instead of something easy to remember when you're stretching it into a good password anyway? We're trying to keep things simple here!) into "0904572d42fdd0ef1cd93fb1047fe2d0." That's a great password! Look how long and random it is! And without involving super complicated hard to learn software like Keepass.

Don't make this more difficult than it has to be, just use md5.

Edit: Holy poo poo you guys, this post was joke response to a post that I'm still pretty sure is itself a joke. I mean I called Keepass "super complicated and hard to learn," because he said "Please don't suggest Keepass, I'm looking for simplicity," after asking for help with a hilariously convoluted method of creating passwords. I don't think anyone who actually thinks Keepass is super hard would be able to find the "Post" button.

Theris fucked around with this message at 18:57 on Nov 20, 2015

Lain Iwakura
Aug 5, 2004

The body exists only to verify one's own existence.

Taco Defender

DeaconBlues posted:

Nice thread topic!

I'd like an effective and relatively simple way of turning a short password into a hash type string to use as a passphrase for AES encryption please.

In the past I've used the MD5 of a simple string (such as a car license plate) and I know that people here will poo poo brix that I used something as insecure as MD5 but, hey, it's better than the original password!

I looked at PBKDF2, which seems ideal for stretching a simple password into an indecipherable string and then found out that there are better alternatives, such as bcrypt which has more expensive overheads if someone attempted to reverse the data.

The problem with bcrypt (and scrypt, I believe) is that they are geared toward storing passwords for web services and produce a more complicated output than I desire. I just wanna derive an encryption key from a simple string.

PBKDF2 looks the sort of thing I'm after but there doesn't seem to be a standardized implementation of it. I want to encrypt something with the knowledge that I can decrypt the file in maybe 5 years time, possibly using a different OS (it will still be Linux based, though) or platform. At least MD5 and SHA256 are both standardized algo's and produce the same result over all platforms.

What do you guys use to manually scramble your passwords?
Please don't suggest keepass2: I'm looking for simplicity. Thanks.

http://forums.somethingawful.com/showthread.php?threadid=3723583

Read this. And yes. You'll want a password manager.

Theris posted:

What's wrong with MD5? I mean, it turns my street's name (why are you using license plate numbers instead of something easy to remember when you're stretching it into a good password anyway? We're trying to keep things simple here!) into "0904572d42fdd0ef1cd93fb1047fe2d0." That's a great password! Look how long and random it is! And without involving super complicated hard to learn software like Keepass.

Don't make this more difficult than it has to be, just use md5.

You're giving horrible advice.

Here's a presentation I gave on Wednesday on why you don't use MD5 for these things: https://afreak.ca/content/share/OWASP%20-%20November%202015.pdf

Wiggly Wayne DDS
Sep 11, 2010



DeaconBlues posted:

Nice thread topic!

I'd like an effective and relatively simple way of turning a short password into a hash type string to use as a passphrase for AES encryption please.

In the past I've used the MD5 of a simple string (such as a car license plate) and I know that people here will poo poo brix that I used something as insecure as MD5 but, hey, it's better than the original password!

I looked at PBKDF2, which seems ideal for stretching a simple password into an indecipherable string and then found out that there are better alternatives, such as bcrypt which has more expensive overheads if someone attempted to reverse the data.

The problem with bcrypt (and scrypt, I believe) is that they are geared toward storing passwords for web services and produce a more complicated output than I desire. I just wanna derive an encryption key from a simple string.

PBKDF2 looks the sort of thing I'm after but there doesn't seem to be a standardized implementation of it. I want to encrypt something with the knowledge that I can decrypt the file in maybe 5 years time, possibly using a different OS (it will still be Linux based, though) or platform. At least MD5 and SHA256 are both standardized algo's and produce the same result over all platforms.

What do you guys use to manually scramble your passwords?
Please don't suggest keepass2: I'm looking for simplicity. Thanks.
Write a passphrase, as in a long phrase not md5("password"), in a book if you can't remember it. Get an actual password manager rather than that amazingly convoluted and ineffective practice you're exercising already. If you're new to security then there's the regular thread to pick up the basics and ask questions. By the way op you'll get chatter with the industry in the yospos security thread.

Theris posted:

What's wrong with MD5? I mean, it turns my street's name (why are you using license plate numbers instead of something easy to remember when you're stretching it into a good password anyway? We're trying to keep things simple here!) into "0904572d42fdd0ef1cd93fb1047fe2d0." That's a great password! Look how long and random it is! And without involving super complicated hard to learn software like Keepass.

Don't make this more difficult than it has to be, just use md5.
Where the hell are you all learning this dogshit advice, nevermind being under the impression you can advocate its security impact

Antillie
Mar 14, 2015

When I need to encrypt something in Python before I write it to disk I use the simple-crypt module. Despite its use of PBKDF2 with a 256 bit random salt I still tend to use the SHA256 of some random phrase as the initial password. In my specific use case I am trying to protect data that a user might backup to some sort of external drive or dropbox account. So if the USB drive is lost or the dropbox account is compromised all the attacker gets is a pile of AES encrypted gibberish since the python program that contains the password is stored elsewhere and not backed up by end users.

Scikar
Nov 20, 2005

5? Seriously?

Antillie posted:

When I need to encrypt something in Python before I write it to disk I use the simple-crypt module. Despite its use of PBKDF2 with a 256 bit random salt I still tend to use the SHA256 of some random phrase as the initial password. In my specific use case I am trying to protect data that a user might backup to some sort of external drive or dropbox account. So if the USB drive is lost or the dropbox account is compromised all the attacker gets is a pile of AES encrypted gibberish since the python program that contains the password is stored elsewhere and not backed up by end users.

Your use case seems better suited for public-private key crypto rather than symmetric key like AES, and PGP already exists to do this for you.

Rufus Ping
Dec 27, 2006





I'm a Friend of Rodney Nano

Theris posted:

What's wrong with MD5? I mean, it turns my street's name (why are you using license plate numbers instead of something easy to remember when you're stretching it into a good password anyway? We're trying to keep things simple here!) into "0904572d42fdd0ef1cd93fb1047fe2d0." That's a great password! Look how long and random it is! And without involving super complicated hard to learn software like Keepass.

Don't make this more difficult than it has to be, just use md5.

seems legit

Only registered members can see post attachments!

Theris
Oct 9, 2007

Wow. I was considering throwing "What is wrong with you? Just use keepass." in spoiler tags, but it really seemed like he was joking so I just went with it. Poe's law is a bitch. :smith:

Theris fucked around with this message at 18:44 on Nov 20, 2015

Rufus Ping
Dec 27, 2006





I'm a Friend of Rodney Nano
poe's law

Antillie
Mar 14, 2015

Scikar posted:

Your use case seems better suited for public-private key crypto rather than symmetric key like AES, and PGP already exists to do this for you.

If I ever need to change things so that each user's data is encrypted with a unique key then I would certainly go with 2048 bit RSA and generate a unique public/private key pair for each user. However at the moment each user only has access to their own data in their home directly due to filesystem permissions and anyone with root can already see the data I am trying to protect anyway.

I suppose I could replace the current way I am doing things with a single public/private key pair but I don't see what that would do other than slow things down. Or am I just not understanding your suggestion correctly?

pr0zac
Jan 18, 2004

~*lukecagefan69*~


Pillbug

Theris posted:

What's wrong with MD5? I mean, it turns my street's name (why are you using license plate numbers instead of something easy to remember when you're stretching it into a good password anyway? We're trying to keep things simple here!) into "0904572d42fdd0ef1cd93fb1047fe2d0." That's a great password! Look how long and random it is! And without involving super complicated hard to learn software like Keepass.

Don't make this more difficult than it has to be, just use md5.

Just use a password manager you doofus. KeePass is free.

Scikar
Nov 20, 2005

5? Seriously?

Antillie posted:

If I ever need to change things so that each user's data is encrypted with a unique key then I would certainly go with 2048 bit RSA and generate a unique public/private key pair for each user. However at the moment each user only has access to their own data in their home directly due to filesystem permissions and anyone with root can already see the data I am trying to protect anyway.

I suppose I could replace the current way I am doing things with a single public/private key pair but I don't see what that would do other than slow things down. Or am I just not understanding your suggestion correctly?

Sorry, I misread your previous post and thought you were backing up the user data yourself.

Daman
Oct 28, 2011
don't joke about my insecurity

DeaconBlues
Nov 8, 2011
It wasn't a joke post. Yep, I do use a password manager (LastPass) but I knew there'd be people recommending Keepass so I mentioned I don't want to use it.

In my case I want to stretch a simple, easy to remember password into a long key. Whoever suggested that I am using multiple instances of this technique are wrong. 99% of my passwords are unique and are stored in LastPass (with 2FA via YubiKey, so don't get smart on me and keep mentioning Keepass).

The point is that I want to stretch an easy to remember brain password into a long key for use with AES encryption which I will only use on a couple of files that are important to me.

Wiggly Wayne DDS
Sep 11, 2010



DeaconBlues posted:

It wasn't a joke post. Yep, I do use a password manager (LastPass) but I knew there'd be people recommending Keepass so I mentioned I don't want to use it.

In my case I want to stretch a simple, easy to remember password into a long key. Whoever suggested that I am using multiple instances of this technique are wrong. 99% of my passwords are unique and are stored in LastPass (with 2FA via YubiKey, so don't get smart on me and keep mentioning Keepass).

The point is that I want to stretch an easy to remember brain password into a long key for use with AES encryption which I will only use on a couple of files that are important to me.
The problem is you're making an intentionally obtuse 'solution' to a problem and asking everyone why it doesn't work well. You want an actual passphrase, in other words a password: "That should be secure and not completely idiotic", "Doesn't involve key-stretching and brain passwords", "Or whatever other pseudosecurity bullshit I've picked up today".

Does that help?

DeaconBlues
Nov 8, 2011
No it doesn't help. This helps:

Is the use of a long string of pseudo-random digits as a key for AES encryption more secure than a short password that one can remember?

Answer me that and you'd be helping. x

Alereon
Feb 6, 2004

Dehumanize yourself and face to Trumpshed
College Slice
:siren: Please stop ruining the security thread :siren:

wyoak
Feb 14, 2005

a glass case of emotion

Fallen Rib

DeaconBlues posted:

No it doesn't help. This helps:

Is the use of a long string of pseudo-random digits as a key for AES encryption more secure than a short password that one can remember?

Answer me that and you'd be helping. x
I'm confused as to what you're trying to but maybe SHA256 but again I'm not sure what the hell you're trying to accomplish

Antillie
Mar 14, 2015

DeaconBlues posted:

No it doesn't help. This helps:

Is the use of a long string of pseudo-random digits as a key for AES encryption more secure than a short password that one can remember?

Answer me that and you'd be helping. x

Well if you are using AES-256 then you must use a key that is exactly 256 bits in length. So whatever you are using to perform the encryption must expand the password that you give it to a 256 bit value. This is generally done with some form of hashing. Exactly how this should be done and why is highly complex and beyond my limited knowledge of encryption.

As I see it, if the attacker doesn't know how you expanded your password into a 256 bit value then they are left trying to guess the key which is basically impossible with AES. But if they do know how you expanded your password into a 256 bit value then all they have to do is guess the password. So I would say that in the latter case, a long string of pseudo-random characters would be more secure than a short password.

I think that PBKDF2 and bcrypt are probably the best ways to do what you are wanting. The downsides you mentioned are just side effects of these methods not being terrible. I suppose if you are going to go with a hash then SHA256 is probably the way to go as it syncs up nicely with AES-256's key size. Although reading through OSI bean dip's presentation using a straight up hash like this is apparently a bad idea when talking about storing passwords. I am not sure if or how that applies to symmetric encryption keys. I guess it probably depends on your specific use case and how often you change the key but I don't really know.

As I said earlier, I feed a SHA256 hash of a long random phrase to Python's simple crypt module as a password to encrypt things. But the simple crypt module itself employs PBKDF2 to generate the actual encryption key. My reason for this is that it is very easy to tell if something has been encrypted using simple crypt. So in my case an attacker knows exactly how I expanded my password into the encryption key and therefore I need to use a very long and pseudo-random password.

Antillie fucked around with this message at 21:30 on Nov 20, 2015

Lain Iwakura
Aug 5, 2004

The body exists only to verify one's own existence.

Taco Defender

DeaconBlues posted:

No it doesn't help. This helps:

Is the use of a long string of pseudo-random digits as a key for AES encryption more secure than a short password that one can remember?

Answer me that and you'd be helping. x

Learn a bit about password strength here. How about we look at some random examples here using results from KeePass's entropy to quality alogrithm:

password (11 bits/8 characters)
1234567890 (6 bits/10 characters)
SomethingAwfulDotComForums (60 bits/26 characters)
1320 West 4th Street (74 bits/20 characters)
654635489476516489475321 (64 bits/24 characters)
CorrectHorseBatteryStaple (96 bits/25 characters)

To achieve 96 bits like the last example, you'd need have a truly random number in order to not end up with it being guessed. Hell, 96-bits is not even something you'd want as if you're actually interested in being reasonably secure, KeePass suggests aiming for 128 bits or higher. This is why we're pouncing on "using random numbers" here because you're never going to get suitable password entropy.

Here's a phrase that exceeds 128-bits: "DietCornFlackMcDonaldsSushiGross!". This is 33 characters long and would be quite difficult to guess.

And guessing is where the idea of using an address you know is a bad idea. If you are in a situation where law enforcement wants access to an encrypted file vault of yours, they're going to build up a dossier on who you are and what you do. In one case, it was someone's cat but that is what the FBI and others will do: they'll learn your life and form lists of possible passwords and such.

Don't do random numbers that you can recite off of your head and actually come up with something you can remember and has enough entropy. It doesn't matter if you're doing key stretching here as if the fruit is low enough, it'll be guessed.

dougdrums
Feb 25, 2005
CLIENT REQUESTED ELECTRONIC FUNDING RECEIPT (FUNDS NOW)
I'm tired of seeing the phrase "don't roll your own crypto". Yeah it's good advice if I'm trying to make web 2.0 mobile next big apps or whatever, but it's really loving annoying when you're learning about cryptography and some pile of meat stuck to a mouse replies with, "don't you know better than to ask :smug:". It makes me think that the person who states it actually knows nothing about cryptography and is trying to cover up their personal insecurity with some cultist utterance.

It's about ethics in cryptography.

Antillie
Mar 14, 2015

I don't think there is anything wrong with rolling your own crypto for the purposes of learning about crypto. But if you are going to do something important you should always use an established and well vetted encryption system instead of trying to come up with something yourself.

Of course you can always just study existing encryption systems to learn about crypto and save yourself the time of trying to write your own for learning purposes. I imagine that writing an implementation of RSA or AES would be quite educational. If only to teach me how not to implement an encryption system as I am certain that I would screw something up in the process of writing the implementation.

DeaconBlues
Nov 8, 2011
Thanks for the last few replies. Entropy is an interesting concept.

I'll keep my particular case simple. Here's what I think I should do:

1. Hash the simple password that's only in my head. Lets say my password is this car registration: "E207HVT".

2. SHA256 of E207HVT=baff2ddde4043bfcfe6dbf67ecfca2b5f8a3a90e7b4939632ce82565c3fe25b2

3. Encrypt the file using AES using the hash of simple brain password and store the file onto SSD/USB/whatever.

I get burgled and the thief is quite good with computers, but no genius.

The thief now has to try and brute-force a 64 character string, rather than a 7 character string.




Am I doing it right?

dougdrums
Feb 25, 2005
CLIENT REQUESTED ELECTRONIC FUNDING RECEIPT (FUNDS NOW)
Right, perhaps not if you are producing a product, but it is good to have an understanding of its use. It's a matter of trust in that regard. I understand how RSA and AES and SHA work, but not when it comes to using ECDH or different padding or something. I trust those (and their implementations) by virtue of my understanding of them, and by knowing the situations of where they do start to unravel. But I've only ever had to implement ElGamal, and it was not fun and it would had been easier to use a proper one.

I dunno, I had an argument with some developers of some open source crypto application over not using the NIST curves or EC at all as the default scheme simply because none of us were actually well versed in how they work. They're faster, sure, but that's not the point ...

dougdrums fucked around with this message at 21:54 on Nov 20, 2015

Antillie
Mar 14, 2015

Well its better than no encryption but I am not an encryption expert. However if the thief realizes that you are using a SHA256 hash for your AES key then all he has to do is guess the string that you initially fed to the hash function. And 7 characters is pretty drat short when you are talking about guessing a password.

For the specific case you mentioned why not use something like VeraCrypt? It was designed specifically for the situation you just described and its free.

OSI bean dip is right about passwords, they need to be long. "LowFatCrudeOilPopTartsWithGraniteWaffelsAndAntifreeze" is where it's at.

Antillie fucked around with this message at 22:00 on Nov 20, 2015

dougdrums
Feb 25, 2005
CLIENT REQUESTED ELECTRONIC FUNDING RECEIPT (FUNDS NOW)
For serious things I use a nonsense sentence, or a dumb joke I haven't told anyone, and remember it and the steps I use to manipulate it. Sometimes this involves Cyrillic or Chinese characters if allowed. I'm pretty sure that's the best any human can do.

DeaconBlues
Nov 8, 2011
What you've mentioned there, dougdrums and Antillie, were my concerns about just using a hash. Particularly about the thief knowing about hashing and trying various hash algo's during the brute-force attempt.

From the bits and bobs I have read, PBKDF2 and bcrypt are better than simple hashing because they utilize CPU and RAM more when doing a calculation. So if the attacker's PC is capable of performing a SHA256 hash in 0.001 seconds it might take the same PC 0.1 seconds to perform a PBKDF2 function. When you consider the number of permutations that the attacker has to generate before he/she finds the key that can make a major difference in time. I can only guess, but the difference between using a simple hash and PBKDF2 to find a 20 character password might be a difference of taking a few hours to a few years if each calculation is 100 times slower.

Lain Iwakura
Aug 5, 2004

The body exists only to verify one's own existence.

Taco Defender

dougdrums posted:

I'm tired of seeing the phrase "don't roll your own crypto". Yeah it's good advice if I'm trying to make web 2.0 mobile next big apps or whatever, but it's really loving annoying when you're learning about cryptography and some pile of meat stuck to a mouse replies with, "don't you know better than to ask :smug:". It makes me think that the person who states it actually knows nothing about cryptography and is trying to cover up their personal insecurity with some cultist utterance.

It's about ethics in cryptography.

There's a difference between writing an application that uses pre-existing libraries in a safe manner and writing your own cryptographic libraries (where "rolling your own" comes from).

Two examples of where people have rolled their own failed crypto include Cryptocat (read details here) and another where someone implemented RSA using PHP. Of course, the developer posted it to Github (said developer removed it so I just have a tweet) and then its terrible implementation was rolled into other projects. You get great comments like this in the code too:



Any basic understanding of prime numbers would be enough to not let you wonder about why these are the largest pairs. I am not going to explain what is wrong in this code because if you're asking this then you shouldn't dare think about writing such.

When those of us who work in the security industry say "don't roll your own", what we're saying is use the libraries that have been tested and vetted. We do have examples of those failing but they're typically going to fail in other ways than what you will do.


DeaconBlues posted:

2. SHA256 of E207HVT=baff2ddde4043bfcfe6dbf67ecfca2b5f8a3a90e7b4939632ce82565c3fe25b2
[...]
Am I doing it right?

Not really. Don't do it this way for reasons I just posted. You're spending too much time making it more complicated than necessary.

Antillie posted:

For the specific case you mentioned why not use something like VeraCrypt? It was designed specifically for the situation you just described and its free.

First of all, don't link to Sourceforge if you're going to suggest a security tool. They've bunded adware with projects that they claimed were "abandoned".

Second of all, anything derived from TrueCrypt should not be trusted.

Lain Iwakura fucked around with this message at 22:28 on Nov 20, 2015

Adbot
ADBOT LOVES YOU

Antillie
Mar 14, 2015

OSI bean dip posted:

First of all, don't link to Sourceforge if you're going to suggest a security tool. They've bunded adware with projects that they claimed were "abandoned".

Second of all, anything derived from TrueCrypt should not be trusted.

I guess you can get Veracrypt from Codeplex instead if you are worried about that sort of thing. Sourceforge was never the official place to get GIMP anyway. Also the results of the code audit of TrueCrypt prove that it and by extension its open source derivatives are solid and can in fact be trusted. Stop spreading FUD.

Antillie fucked around with this message at 22:37 on Nov 20, 2015

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply