Cryptography

Vera. It's not for anything too top secret though. What do you guys use it for?

I personnaly use Truecrypt 7.1a
but some time is usefull tu use openssl

>he doesn't assign sections of the file to a piano key and arrange it so that it plays bach to the unsuspecting, but can be decoded using the recovery file
>laughing qtpies-who-just want-everyone-to-be-happy.bmp

>>56223217
>using the recovery file

what do you call a recovy file ?

>>56223180
>aes-256

No.

why no for aes 256 ?

>>56223180
>what cryptography software do you use?
disk: LUKS/dmcrypt
everything else: gpg

>>56223180
>CBC
when will idiots ever learn?

File: 1454609622101.jpg (45KB, 480x640px) Image search: [Google]

45KB, 480x640px

I definitely don't use openssl you shouldn't too. The command you posted encrypts the file using only 80 bits of the password because the default KDF enc is still MD5.

okey, so cbc is not good ?
what can i use ?

only gpg ?

>>56223458
LUKS/dm-crypt or gpg is what I'd recommend

>>56223487
thanks for advice =)
what is the strongest algo or mode using gpg ?

I store all of my pornography in a few large veracrypt volumes. Whenever I want to view or move stuff around, I input my 65 key password (slightly tweaked for each volume).

I'm not on my desktop and I'm too lazy to go check but I'm pretty sure the encryption is AES-Twofish-serpent

There is no real reason for the extensive security for my porn. It's mainly pretty vanilla stuff with Jap and Hentai mixed in. I don't really have a taste for more "deviant" fetishes either. I'm just worried about what would happen if I were to die unexpectedly someday. The last thing I want is for my family or friends to find my huge porn collection.

Or even if my comp parts get recycled, it'll prevent the guys working at the recycling plant from having a laugh after finding my stash.

>>56223494
This is what I use

s2k-mode 3
s2k-cipher-algo aes256
s2k-digest-algo sha512
s2k-count 65011712

cert-digest-algo sha512
personal-cipher-preferences twofish,aes256,aes
personal-digest-preferences sha512,sha384,sha256

>>56223514
thanks you so much,

i am looking for the full command now =)

>>56223505
it's not for porn
but for confidentiality coworker file for my job ^^

>>56223231
the file that reverses the bachifying so you end up with the original file

>>56223385
In this day and age it's good practise to assume that anything NSA has touched has backdoors baked in and/or they have knowledge of zero-day mathematical vulnerabilities that could be exploited to weaken the cryptographic functions

>>56224337
>>>56223385
>In this day and age it's good practise to assume that anything NSA has touched has backdoors
Okey so what did they have not touch ?

>>56223385
>Tons of software uses AES
NSA does nothing
>Truecrypt uses twofish and serpent
NSA kills the creator and shuts it down

how can i use GPG to crypt a file using AES twofish and serpent same time?

i have found this

gpg --armor --symmetric --cipher-algo TWOFISH file.tar.gz 

can it be improve?

>>56223180
cryptography thread and you talk about software to encrypt shit instead of interesting maths and algorithms and code

baka fuck /g/ im out

>>56224609
you can speak about maths and algorithms
i am open =)
but software is also important than math.
No ?

>>56224634
No

>>56224609
can we talk about memecoins?

libsodium; Noise; Signal; Tor; GnuPG; boringssl; dm-crypt.

Also Bitlocker (why not if I'm trusting Windows code on my desktop anyway). VeraCrypt might be viable soon but I have little faith in the new maintainers to pass that audit in one piece, they can't even use GPG properly.

>>56224434
Paul's still alive. And that's not why anyone would be irked with him. He's an, um, interesting fellow.

>>56224337
That is not credible for most things. They didn't make AES (Rijndael). The SHA-1 and SHA-2 functions were the best anyone could have done at the time and were not backdoored, although BLAKE2 and Keccak are both better modern choices. I prefer ChaCha20-Poly1305 to AES256-GCM as an AEAD for many reasons, including how hard software AES is to defend against cache timing attacks, and how rapidly GCM weakens compared to better modes - a QPF algorithm recently found means it may not survive a quantum computer either.

Conversely, Dual_EC_DRBG smelt fishy from day 1 and everyone was saying it - that some people used it anyway, that's the suspicious part.

When they want to steal keys, they tend to get TAO to hack them. Much simpler. See the recently disclosed Cisco exploits.

>>56224601
--armor is only needed if you plan on sending something via plaintext e-mail. For regular files it's extremely wasteful

I would leave it away unless you absolutely need it

>>56224609
Feel free to ask any questions you have about crypto maths and algorithms?

How do you expect there to be a discussion if there's nothing to discuss?

>>56224894
NIST didn't make the AES finalists, but it did have the ability to influence the decision.

The problem with encryption standardization competitions is that it's hard to quantify the “security” of a cryptographic algorithm. Every single algorithm is always only going to be as secure as the best known attack - but for “new” algorithms there's not enough cryptanalysis available.

Often, in lieue of “security” being a measurable trait, the standardization process tries comparing performance instead. For example, AES was picked because it's easier to implement in hardware than something like Twofish or Serpent, which was primarily the case because of design decisions like AES using the minimum number of rounds it could get away with (rather than Serpent, which added a few extra padding rounds just in case) - and because of its key schedule which is easy to implement efficiently, at the cost of having slightly less strong properties. (And if AES is broken, it will probably be as result of an attack on the key schedule, in the form of related key attacks or otherwise)

So what the NIST can do is e.g. guide the standardization process away from “cryptographically harder” algorithms and towards “weaker but faster” algorithms by getting people to agree that faster is better, in the hopes of making the resulting encryption standard easier to attack.

That said, there is no current indication that the NSA has broken AES (which was in fact explicitly refuted by the time of the snowden documents)

>>56224434
In 99.9% of cases, attacking the cryptography is significantly harder than attacking the software itself - and the NSA knows it.

I strongly doubt they have broken AES to this day, even if they do have good ways of subverting the encryption used by 99.9% of programs (based on side channels and other ways to defeat the cryptography by going around it).

LUKS with aes-xts-plain64 and sha256.

Is there a single asymmetric encryption algorithm that can survive quantum computing? Even things like 8K RSA are trivial to break.

Fucking GPG is as weak as it's asymmetric part.

Here's a question for y'all:

According to “cryptsetup benchmark” I can get about 1 GB/s of AES throughput per thread.

If I have a RAID spanning 10 encrypted drives, and I have each drive mounted separately using cryptsetup/LUKS/dmcrypt, does each drive get encrypted by a separate thread, i.e. can I get 1 GB/s throughput per drive, or will I have to divide that 1 GB/s by the number of drives in my RAID?

>>56225462
You would be better off making a raid of the disks first and then encrypting that layer, not the other way around

>>56225444
ECDSA perhaps?

>>56225462
The 1GB/s is the amount the kernel can encrypt/decrypt from one memory buffer to another.
With RAID 0 or 1 at least, it should give you full speed.

>>56225516
Unfortunately zfs/btrfs don't work that way - the RAID is built into the filesystem, so I can't raid-before-encrypt

>>56225444
In practice? No. In principle/theory? Yes, most notable lattice-based cryptography

See https://en.wikipedia.org/wiki/Post_quantum_cryptography

Good luck getting people to switch to quantum-proof algorithms before it's too late, because the overhead is much higher.

>>56225729
Nope, ECDSA is just as weak as disclog

>>56223231
>>56223385
>>56224337
>>56223458
>>56223494
>>56224413
>>56223538
>>56224601
>>56224634

ITT PoojeetPosting

15 Rupees have been deposited

Winrar with password

>>56226211

registered copy btw

>>56225817
>can I get 1 GB/s throughput per drive, or will I have to divide that 1 GB/s by the number of drives in my RAID?
That depends if that 1GB/s number is with parallel crypto engine (or whatever that kernel setting is called) or not. With regular single threaded you could theoretically see 1GB times the cores divided by disks

>>56227052
>That depends if that 1GB/s number is with parallel crypto engine (or whatever that kernel setting is called)
Oh, that's an interesting pointer. I didn't know such an option existed. I had it off, apparently. Thanks!

>>56224434
Go research the AES finalists and see why Serpent wasn't chosen as the winner.

It was a bit slower than AES but had notable advantages.

Use Serpent.

>>56225444
Yes. The big things you need to watch out for is that anything based on hardness of factoring or discrete log is generally dead as a doornail, and everything else is square-rooted or cube-rooted.

To keep a 2^128 work factor with a big, fully-entangled quantum computer in the mix, 256-bit symmetric algorithms like ChaCha20, Serpent-256 or AES-256 will probably survive. Hashes or XOFs need to be 384 bits or greater (birthday attacks get cube-rooted by a sort of quantum meet-in-the-middle), so 512-bit ones like Keccak or BLAKE2 are probably good.

For asymmetric primitives, the options aren't as attractive. William White has been trying to push NTRU since the 90s and the NSA picked ECDSA over it (probably because of patents, is my guess actually) - lattice-based algorithms are one option but there remains considerable disagreement about the strength of their reductions.

Code-based, particularly Ring-LWE, provides another interesting D-H alternative, and NewHope is a recent candidate Google and Tor are trying alongside traditional elliptic curve key agreement. Better ones exist, fruitful field.

I've been looking at supersingular isogeny Diffie-Hellman recently; a post-quantum key exchange using isogenies over elliptic curves rather than anything based on the difficulty of discrete logs over the field (which are of course easy with a quantum computer).

Kind of slow compared to Ring-LWE and ideal lattice, but can do a static D-H and sigs too. Might hold up better against quantum period finding? Early to tell.

Signatures, we have lattice ones but they lose security with each signature. There are hash-based Lamport-Merkle signatures - those are good, but require state, except for the neat ~47KB SPHYNX one.

All a bit up in the air right now I'm afraid.

>>56223180
Not OP.

Which is the one that is open source and works with a key-file I can keep on my owncloud storage? I want that key-file to be safe if it somehow gets in the wild without my password. But it will be kept in own-cloud on my server in my closet that is only connected to through my vpn. Its not open to the outside as securing one vpn is easier then securing everything that I might want from the outside.

I know the keyfile could be out of date if a machine doesnt contact the owncloud for a while but I can handle that.

>>56227261
There's probably nothing wrong with AES for the foreseeable future. Serpent also seems OK. Watch out for side channel in both. Salsa20 and ChaCha20 are safer in that regard.

Pay more attention to your block cipher modes, that's where people fuck things up.

We later discovered Serpent can be efficiently bitsliced incidentally, which the Linux dm-crypt implementation of serpent-xts does. This is why, unless you have hardware AES-NI, you might well find that serpent-xts-256 is not only the algorithm with the highest security margin, it might also be the fastest.

Considering the NSA have been caught using RC6 (yes, one of the shittier AES competition rejects) in OFB mode, and Dual_EC_DRBG in production even though it's biased even without the 'key', not to mention one of the Suite A algos is based on LFSRs, I can tell you they're not made of wizards. Just money. Lots of money to bribe RSA Security, Juniper, Cavium, Broadcom, SafeNet, Cisco employees, etc.

That practice doesn't work so well against anything published in the open and not designed by shit committee.

>>56227551
No construct works very well in that scenario.

What you probably want to do instead is to use a strong passphrase with over 100 bits of real entropy - 10-word Diceware has 129 bits. Keep that safe. Maybe IN a safe. Or your head if you can reliably remember it. Do NOT put it in online storage.

Bear in mind the block cipher modes used by any full disk encryption software, like CBC or (better) XTS, have no authentication - there's no room for a MAC or tag for an AEAD to be used, as that would require extra space, the only practical way of dealing with which would be to make the logical sector size smaller than the physical sector size (say, by 16 bytes), and that crashes fucking everything, nothing is prepared for weird logical sector sizes (last tried back in PGPdisk ckt).

Without that authentication, make sure to never put an encrypted volume (be it BitLocker, TrueCrypt, VeraCrypt, dm-crypt, whatever) on anything an attacker can observe more than once or change at all.

Plus all the Evil Maid troubles there. In particular that means cloud storage and encryption are very dangerous things to mix: you're trusting what you're uploading it to to not be evil on an ongoing basis, but keep the keys or the passphrases that unlock them locally.

Your use of "keyfile" makes me think TC/VC, and keyfile are NOT suitable for that purpose.

Shame the docs arent around anymore, the old TC site had a lot of good info on this before the incident.

OpenBSD's full disk encryption

>>56227681
http://andryou.com/truecrypt/

>>56227052
>>56227103
Turned it on now. “cryptsetup benchmark”'s numbers are still the same, but I guess that's expected?

>>56227566
>Pay more attention to your block cipher modes, that's where people fuck things up.
Especially padding. Fuck padding. ChaCha20-Poly1305 all the way.

>>56227391
>>56227566
>>56227681
You know what you're talking about; what's your opinion on elliptic curves?

Something bothers me about having to trust some arbitrary constants. There's no such thing as a “nothing up my sleeves number”, so how do I know curve 2^255-19 or w/e is really safe to use?

Do I just have to trust djb blindly? Also, with all of the “mistakes” you can make while picking an elliptic curve, how do you rate the chances that Ed25519 is going to end up being in some as-of-yet undiscovered set of bad curves like the ones we already know about?

File: 1468448100358.jpg (121KB, 768x1024px) Image search: [Google]

121KB, 768x1024px

>>56223180

LUKS header information for /dev/sda3

Version:           1
Cipher name:       camellia
Cipher mode:       xts-plain64
Hash spec:         whirlpool
Payload offset:    4096
MK bits:           512

>>56228430
not him but i would say say away from NIST curves since they cannot be trusted due to concerns with the NSA
>>56228474
How's the performance with camellia?

>>56229728
>How's the performance with camellia?
Not him but,

     aes-xts   256b  1027.4 MiB/s  1023.7 MiB/s
 serpent-xts   256b   233.9 MiB/s   226.9 MiB/s
 twofish-xts   256b   231.9 MiB/s   192.4 MiB/s
camellia-xts   256b   432.0 MiB/s   432.8 MiB/s

hth

Do you guys trust veracrypt

>>56230470
nope

>>56223399
>>56223487
How secure is the default LUKS thing from the Linux installer? I never really found much about that technology, but everything else seems to be a hassle on Linux.

>>56230700
wat

>>56230732
Most Linux installers offer some basic device encryption option. It's probably about the same as:
sudo cryptsetup -y -v luksFormat /dev/sd?X

I'm just wondering how secure it is compared to other tools. Also are there recommended advanced settings one should use?

>>56230827
Oh, sure. They'll be fine. The mechanism is the same, it's just a front-end.

Worst thing they would do is use AES by default, which is the best for performance by far but you may want to use a different algorithm if you're a tinfoil hat nutter

>>56230827
>>56230872
I you want to know for sure, run

cryptsetup luksDump /dev/sd?X

after the installation and see what settings it picked

I used to use truecrypt but that all went down the shitter after 7.1a. But technically isn't 7.1a just as bad as any version to follow afterwards? Wouldn't the NSA have gone and looked over previous versions too?

Also, what program uses chacha20-poly1305?

>>56230893
>Also, what program uses chacha20-poly1305?
linux kernel crypto implements it, but it's not available for cryptsetup yet apparently

(I think block ciphers would perform better anyway)

>>56230892

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        256

How fucked am I? This is the default setting of ubuntu server 16.04. It's a virtualization box, so I don't want to bottleneck the IO too much.

File: anteater.jpg (75KB, 600x688px) Image search: [Google]

75KB, 600x688px

Botan is the comfiest crypto library
trufax

>>56231003
>so I don't want to bottleneck the IO too much.
Have you run

cryptsetup benchmark

?

>what cryptography software do you use?
Pleb. Get on my level.

Cryptography is not about software, but about practices. There is no software for managing your identities, or keeping your lips non-loose.

It's like lessening the act of running into nothing but one's choice of shoes. I am mad. I am so triggered by the idiocy of this thread.

File: sunny.png (92KB, 500x439px) Image search: [Google]

92KB, 500x439px

>>56231063
?

>>56231003
Seems fine.

I wonder why they use sha1 by default but afaik it's only used for KDF so it doesn't really matter.

>>56231003
Also, how many iterations does your key use? (should be listed under the key slots)

File: giphy.gif (1MB, 500x282px) Image search: [Google]

1MB, 500x282px

>>56231063
>being this autistic

>>56231003
>It's a virtualization box, so I don't want to bottleneck the IO too much.
What does

zgrep PCRYPT /proc/config.gz

say?

>>56231011
I-i wonder what would happen if you rubbed your penis on that thing...

DM-Crypt luks
aes-xts-base64 cipher
sha512 hash
512 bit keylength

File: 1edSp4B.jpg (36KB, 384x576px) Image search: [Google]

36KB, 384x576px

>>56223180
Haha nice try NSA!

>>56231034
nope but thanks for the advice. I was just lazy and didn't rtfm.

PBKDF2-sha1       799219 iterations per second
PBKDF2-sha256     442810 iterations per second
PBKDF2-sha512     346751 iterations per second
PBKDF2-ripemd160  598502 iterations per second
PBKDF2-whirlpool  168041 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   191.0 MiB/s   206.4 MiB/s
 serpent-cbc   128b    29.9 MiB/s   236.6 MiB/s
 twofish-cbc   128b   183.5 MiB/s   259.1 MiB/s
     aes-cbc   256b   146.8 MiB/s   155.2 MiB/s
 serpent-cbc   256b    95.4 MiB/s   238.2 MiB/s
 twofish-cbc   256b   211.6 MiB/s   259.4 MiB/s
     aes-xts   256b   200.6 MiB/s   200.0 MiB/s
 serpent-xts   256b   215.1 MiB/s   220.2 MiB/s
 twofish-xts   256b   238.8 MiB/s   236.2 MiB/s
     aes-xts   512b   152.8 MiB/s   150.4 MiB/s
 serpent-xts   512b   216.5 MiB/s   218.5 MiB/s
 twofish-xts   512b   238.4 MiB/s   235.9 MiB/s

I guess I could use stronger encryption since the drive isn't much faster than 200 MiB/s anyways.

>>56231127
More than 400000.

Thoughts on this >>>56224091?

>>56231205
Use Veracrypt after they complete the audit and its officially declared safe. No need to use an outdated version if a more advanced and secure fork of it exists.

>>56223180
ChaCha20 and XSalsa is perfect, AES is NSA ridden, NSA even reccomends AES, do i'm never touching that kind of encryption, just like how I will never touch SELinux, Hardened Kernel for life

>>56231184
Are you on really old hardware? Like, pre-AESNI CPUs? Normally AES should be like 5x as fast as the others

>More than 400000.
Seems reasonable. I just like to crank that up to like 5 seconds - what's 5 seconds of your boot time compared to making it really hard to brutefroce.

>>56231235
>NSA even reccomends AES
Yeah, they recommend using it for their own files (Top Secret class).

Besides, if AES is bunk, you would have expected a Fields Medal for breaking it or something.

>>56231264
Yep it's a AMD Phenom(tm) II X6 1090T from 2010. I could easily buy a new CPU and even save money from the energy savings. But I just cant afford the downtime.

>>56223399

What's wrong with CBC, triple-double? Are you referring to the padding oracle attacks which are a flaw in the TLS implementation of CBC rather than CBC itself?

>>56231326
>can't afford the downtime
I don't buy this. Either your service is large and important enough to be load balanced across multiple redundant machines, or your service can handle a few hours of downtime

>>56231344
CBC is malleable unless you use an extra HMAC

File: 1376247921057.jpg (52KB, 500x434px) Image search: [Google]

52KB, 500x434px

>>56231364
It was just a joke, I'm just too lazy.

>>56231264
>I just like to crank that up to like 5 seconds
On the other hand: 1 gorillian years vs. 5 gorillian years doesn't make much of a difference either.

>>56231378
Also, if you make a change to the .tar.gz and then upload it again, CBC collapses pretty quickly.

>>56223180

AES in XTS or GCM is better than CBC. Google to learn you something.

>>56231498
Wanted to hook in on this, found this thread to be a nice read: https://security.stackexchange.com/questions/40208/recommended-options-for-luks-cryptsetup

File: 61 - Io1d5ac.png (52KB, 234x240px) Image search: [Google]

52KB, 234x240px

Anyone that is having trouble with cipher block modes please refer to the link to read up on it

>inb4 NIST article i don't trust them
Yea you shouldn't trust them but its a good reference

http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf