OpenSSL is compromised apparently. I dunno, I'm from Holla Forums and we'd like your take on this issue...

The thing about randomness is true and a lot of people in cryptography knows it.

That why hardware for the purpose of generating entropy exist (especially the military , they collect sounds and wavelengths to generate entropy (and more) it's impressive).
For more powerful randomness there's
fsf.org/blogs/gnu-press/neug-trng
and there is also this but I doubt the ""opensourceness"
crowdsupply.com/cryptech/open-hardware-security-module

Anyway it needs to be fixed.

does this mean that tor pedos are going to jail?

does this affect encryption algorythms?

Holy shit did any of you read the paste? It's fucking nothing. Try not to get baited by a faggot on a conspiracy website next time.

That would have happened even before it was made public. The public disclosure of bugs in open source is nothing but a good thing because it means that developers can work on a fix.

you forgot to say that all files that were encrypted before the fix will still remain vulnerable thought.

Then go through the process of getting it secure! Security is a continually ongoing process, it's not a property configuration that you can flip somewhere.

what files are we talking about here?

The use of the MD5 sum reduces the security by 50%. If you have the SALT you have the rest.

The security of the MD5 hash function is severely compromised. A collision attack exists that can find collisions within seconds on a computer with a 2.6 GHz Pentium 4 processor.

Its been known that using the MD5 sum was bad since 2008 or something. How to get the SALT would be interesting. You could try to brute-force it but maybe there is a leak that gives a clue to what the SALT is?

Vulnerabilities are published all the time. Unless you have a critical need you wouldn't pay any attention. I just think crypto is fun. If you have sensitive data you might consider encrypting it first with a different encryption method? Watch the Kahn Academy lectures on Crypto to get a basic understanding of decryption too. Any pre-defined algorithm for encryption makes decryption easier. The only solution most people have is to increase the key size. If you use a one-time pad it cannot be broken. Crypto is not having a crisis, although you may be. ;)

youtu.be/fwcl17Q0bpk?t=162

old but good

Doesn't know about Strange Attractors.

...

wew

Proof of concept or fuck off.

got a vector of that? I want to make one as large as 8ch allows

It's all in the fucking paste. Try it yourself if you don't believe it.

newfag here. What are the potential consequences of this?

Anything encrypted with openSSL should be considered compromised, but since the whole heartbleed fiasco you should've assumed that anyway

>>>Holla Forums8723416

Correction: anything encrypted by a retard smashing crypto primitives together at random and thinking it's secure just because AES was involved should be considered compromised

drama queen

This is why rust is superior.

so 90% of software making use of crypto right?
Isn't this also limited to cases where OpenSSL is used with a password to encrypt files? I don't know many cases where this is used seriously, most people would use FDE or Truecrypt or something. This shouldn't affect TLS?

This is all gay though. To get the "seed" password in this proof of concept, you have to have the initial key. You know, the string that is actually used to encrypt the document.

I believe the intention was to prove that OpenSSL was using MD5 as a key derivation function in an insecure way that limits the keyspace when using a password. This should make it easier to bruteforce files encrypted with OpenSSL but I don't think it is the catastrophe it is blowing up to be right now?

Possibly, but its nothing even close to being critical.

What does this mean, if anything, for people using a VPN, Tor or offshore email account?

Inkscape has a tool to produce vectors from images. I'll try to see if I can make it work.

I made a vector, no color because I have no idea how to make SVGs so you can add that in your PNG if you want.

Link expires in 1 month.
a.cocaine.ninja/xpofuz.svg

nature finds a way!

Go fuck yourself

a.cocaine.ninja/xjfpuu.svg
Take it, just edited in text editor (because I don't know how to use fucking graphic editors and it's simpler)

...

Wow, Holla Forums, every time I think you can't get any more fucking retarded, you go and do shit like this and prove me wrong.

Holla Forums is a funny guy sometimes

...

O M G
WHO WOULD HAVE THOUGHT THAT WITH THE PASSWORD AND THE SALT YOU CAN DERIVE THE KEY
Yes, it should use a stronger key derivation algorithm by default, but this is OpenSSL. The defaults are probably more than a decade old, and only get changed if there is actually an attack on that set of parameters.
And concerning the RNG and memory allocator, it's widely known that they're shit. That's one of the reason LibreSSL was created.
This is from 2014: openbsd.org/papers/bsdcan14-libressl/mgp00017.html

DON'T NEED EITHER, I IMPLEMENT

FYI: github.com/openssl/openssl/issues/2195

In other words, the content in the paste is mostly bullshit and bait.

UNTRUE, I HAVE WORKING IMPLEMENT, I MADE OPTIMIZATION, AM HACKING BANK OF ENGLAND NOW BECAUSE THEY COLONIZE THOUGH BUT I HAVE ALL THE MONEY WE WILL SEND YOU OUR POO NOW WE COLONIZE YOU!

Schizophrenia and autism are a hell of a cocktail.

It seems pretty good and I was using it to feed /dev/random, but yesterday I discovered it was hanging my PC on shutdown. Although I don't restart my PC very often, is there a way to feed it to /dev/random without having that issue?

OP here. The main point was to clarify Holla Forums suspicions.
Seems like a potential threat, but might not be as bad as first thought.

Woops. Was on a phone. Should have posted the archive link. See the Holla Forums thread.

We're non tech geeks beginning to learn shit. Be gentle senpai.
We're slowly getting there.

Complacency is for cucks. We're only paranoid because we're learning and do not fully understand the tech holes etc.

One day we might have a larger more tech literate force.

Get out

Holla Forums is always seeing things that aren't there. A bug in openssl? OMG THE NSA BRIBED THE OPENSSL TEAM

Did you read the leaks?
You need to realise you're in hell son. We don't even know how far criminals would go now. I used to think that shit was for windmill crusaders.
Turns out - they were no mere windmills all along. People are living falsely complacent today.

Why is Holla Forums so fucking stupid?

Why are Holla Forums masochists?

Because it is filled full of retards who attack their own because they've been easily co-opted by the SJW mods. Just look at how they've been attacking TRS for the past couple weeks.

I bet you like jews too.

you've never listened to any of their podcasts have you?

case in point tech, just look at this tard

I don't live complacently. I know that the government is willing to intrude on freedoms for their own benefit and for a more intrusive state. The government is no longer accountable to the people. What I don't do is jump to conclusions. I separate the hard facts and my opinions that are derived from those fact. I avoid jumping to conclusions until either the hard evidence proves only one conclusion or the evidence points to a conclusion that is beyond reasonable doubt.

This is the reason why I don't use Microsoft Windows or any form of proprietary software, I don't have a cell phone and why I am extremely selective about what technology I allow in my life. Richard Stallman taught me about freedom and that freedom is a good thing to fight for.

Have you?
No i haven't because i dont bother browsing there. Got links?

There is jumping to conclusions, and there is cognitive dissonance preventing the evidence from fulfilling a threshold of acceptance of a fact.

This is why tech geeks suck at politics and national security. It has to be black and white. Frankly, there are concerns which need preemptive action and you are frightened of considering that because the fact has to be 100% and absolute.

You need to realise that a chain of circumstances is usually all you need to prove a case, because direct evidence is unreasonable.

That said, barely looked at the TRS thread. Seemed rather bullshit. (So i partially agree there)

their podcast is literally called The Daily Shoah. you're really retarded enough to think they dont name the jew?

(Cont.) But the fact TRS are nothing but namefags suggests they are nothing but attention whores that do it for the attention between their peers.

I loathe that. You're not doing it for digging out the truth, you do it for attention.

They are brave to use names then. I will have to look over it. Seems like the mods did shifty things though, and sjws seem to love planting seductive parasites(breaking mods through sex) on these forums.

I know that from personal experience tbh.

The mods hate anything which could threaten people to leave Holla Forums. I was bedchan back in the hotwheels fix your shit, codemoneky fix your shit threads, and they kept on deleting my posts on Holla Forums and banning me.

Did you use the meta thread?

no one goes to polmeta

Not even mods?
That's probably the reason for the ban. You never gave the mods a chance to "correct the record" kek we do need to ask some questions, but faggots will drown out the right qs

Also could i get those images in your previous pic?

Have you ever been to polmeta? Have you ever once seen the mods there?

In the first ban they said to keep it on Holla Forums as hotwheels giving away user data to Vice, and jim in general wanting to be a greedy kike and wanting to ban Tor, was not pol related.

Single fact to back that up, etc.

How new are you? 8ch.net/lorenzolog.txt

I don't understand. You already need the password to do this. Why is this a vulnerability?

some redditcuck emailed openssl about this

tl;dr it's mostly fucking nothing

reddit.com/r/linux/comments/5myb3m/i_got_a_reply_from_openssl_regarding_the_rumours/
archive.fo/y9aVs

yawn, got anything worth actually sperging over? If not nothing you're claiming is fun and you're boring.

are you as illiterate as a nigger?

Haha, didn't know there was a BG fill param.

Inkscape was trying to tell me I needed to make a new shape behind the smiley and fill it in but I didn't think that was a good idea. TY

reddit.com/user/comrade-jim

our guy?

He's either from here or cuckchan, I see him triggering the faggots on /r/linux every time I go there to look for news. I get shadowb& every time I make a new account to shitpost on that cancerous shithole.

That's not what they're doing. What they're doing is showing OpenSSL is just parsing your data through a MD5 hash.

Is OpenSSL of equivalent security to--or is it not--a MD5 hash? Why is that question not answered on plebbit?

Plebe.

Is Dell of equivalent security to--or is it not--a hard drive?
Is our children learning???

Even more to the point, has anyone really been far even as decided to use even go want to do look more like?

English, motherfucker. Do you speak it?

You have no right to talk about security if you ever rely on proprietary software.

Both are you are not answering the question. This makes me rather suspicious because this is a typical sliding technique.

en.wikipedia.org/wiki/Apposition

Why should we answer such a nonsense question? It's impossible to make sense when you're starting with nonsense.

This may or may not affect TLS at all. This does not affect Firefox--Mozilla does not use OpenSSL. The only claimed weakness is a bad RNG, which may or may not also expose a TLS server's private key. Exposing private keys was how Heartbleed caused problems.

The salt is included with the ciphertext. The only actual claimed weakness is an allegation that the salt is not random at all, but is somehow derived from the passphrase. If true, then the initialization vector may also be affected. Both of these are supposed to be "random numbers" and are stored with the ciphertext. Neither the salt nor the IV is secret, only the passphrase is secret. Obviously, it's very bad if secrets can be derived from non-secrets.

The claimed weakness relates specifically to the OpenSSL enc(1) command, which is believed to have been used to encrypt the Wikileaks insurance files. It may or may not also affect programs that use OpenSSL for TLS.

It doesn't affect anything. It's a troll post, with buzzwords throughout. Using md5 in this context does not matter. You got trolled.

I'm less quick to dismiss it in its entirety--but you are correct that it's mostly bogus. The only valid concern that it raises is the claim that the salt is generated in part from the passphrase.

OpenSSL has done similarly bad things in the past, notably using the user's RSA private key as an entropy source. Given the Debian RNG screw-up, which was caused by OpenSSL relying on an "uninitialized" block of memory to contain random bytes and Debian fixing the apparent bug, I won't quickly dismiss claims of further RNG shenanigans in OpenSSL. They've been caught doing stupid shit with their RNG before.

If the passphrase is being used an entropy source for the RNG, then CBC mode introduces another potential side channel--the initialization vector, which is also a non-secret "random" number. Unlike the salt, which is only 64 bits, the IV is as long as one cipher block, which is 256 bits for AES. 256+64 = 320 bits of possible side channel if the RNG uses the passphrase as an entropy source. Depending on exactly how the OpenSSL RNG works (please tell me it isn't Dual EC DRBG) this might give an attacker clues about the passphrase.

There's smoke here, but we don't know if there are any flames yet.

it's nothing

ghostbin.com/paste/o2xcz
ghostbin.com/paste/nprjc
ghostbin.com/paste/xqtea

Yes. You can prove it easily by making a file. The group then went on to preimage MD5.
beamstat.com/chan/de995093c3873da70881ddf0bc1bb0f714ff361e653a1030d193497dbaba6355

Wow, they did something that was already done in 2009. Bravo.
You're reading posts made by morons or aspies who think they're good at crypto.

If you can preimage MD5 you can unlock any file encrypted with OpenSSL. That's the whole point, that you can open it with something that was done in 2009 and what's worse is that you don't even need to preimage MD5.

Actually, that's wrong, there are no known practical preimage attacks on md5, I was mistaken.
You can change the default message digest, if there were a pre-image attack on MD5, for a KDF. Like -md sha256.
The KDF is fine. On further look, you're reading rambling from retards from a website called "Godlike Productions."
The thing about conspiracy retards is that they're really good at rambling and inserting buzzwords to make themselves sound correct.
It's just a fucking moron who doesn't know how to actually use software.

An attack that took 3 seconds to run on a shitty laptop is in beamstat.com/chan/de995093c3873da70881ddf0bc1bb0f714ff361e653a1030d193497dbaba6355

Then why did they respond by changing it?
github.com/openssl/openssl/pull/2083

>(*) see github.com/openssl/openssl/pull/2083, which implements PBKDF2 and a better iteration count than 1.

>Richard Levitte [email protected]/* */ OpenSSL Project openssl.org/~levitte/

That's not where this was discovered. This came from a darknet site that then moved over to a Bitmessage channel to explain the exploit.

It's another option.
Again, the KDF is fine, and you can use another digest if you want, and you can now use PBKDF2 if you want once that patch hits.

Oh, so some fucking retard cross posted the rambling of incompetent aspies across every imageboard and his favorite conspiracy websites. Gotcha.

I'm not reading the rambling of aspies who actually thought that a valid attack was deriving the key when you know both the password and the salt.
It's just laughable. The fact that any of you morons thought this was an 'attack' at the beginning is also hilarious.
Note, after this all was pointed out, the aspie channel moves further into obscurity, with no direct accusations but 1) claiming that they have a practical pre-image attack (no actual evidence, just rambling, begs for access to a machine with 32GB of RAM, obviously a retarded poorfag)
2) moving the channel somewhere else, only you can know where they're going if you follow their autistic instructions, same form of rambling as the retard that thought being able to find the key from the password and salt is an "attack."

So, in summary: LOL.

That was what the idiots that made the pol thread said because they don't understand what they were reading. If you want to understand the real vulnerability read
ghostbin.com/paste/o2xcz
ghostbin.com/paste/nprjc
ghostbin.com/paste/xqtea
beamstat.com/chan/de995093c3873da70881ddf0bc1bb0f714ff361e653a1030d193497dbaba6355

gateway.glop.me/ipfs/QmTsmgrWfQD11CTeGU7nqY379MYf2NycQxPmxrTCUixWDa/zkp.py
python zkp.py

MD5raw('831a81355f15e9513f1aaee402a313e4785d0d7eea5df584fb84a216d698b839ab0cfb26efcec5e79094ae493d79c353c12cdacde1b1dcf9e3414017b3680e18', [0xc7e79d07, 0x41944cd6, 0xba1fa870, 0xe02d503f])
deaddeaddeaddeaddeaddeaddeaddead

MD5raw('fc65b9b5e2981656c0ad4e5962f3ed22c908b2ec2c5a4ae5a442e8900da7faf05ea5b913f5ffe3674e758ab955f16a5b9ce1f7a6ba89bf2d05233ceee2bb1cfc', [0xc0974e7e, 0x78811171, 0x83f5a3cb, 0x2d5a4e86])
deaddeaddeaddeaddeaddeaddeaddead

MD5raw('1e1ed495db2c9f2f090d4475cf24290857859ad23ff2c86adcb493ab4dbefef2260defa5880b18d83358c8635a964a58ef80c954288b031aedd280424f7394a0', [0x935594da, 0x39e88787, 0xe601456c, 0xc48cd364])
00000000000000000000000000000000

MD5raw('95443ad1f92c8b873227350feb0b26ed3b1efc86a1983f3d47363112f4bbb07433f28060f937b8e742abb8e19179268573c29c7e647c21f9b8118eb92c879001', [0xa4ce3da0, 0xcadb2da4, 0x4f10c6f9, 0x3762d5f0])
00000000000000000000000000000000

researchgate.net/publication/225591089_Collisions_for_the_compression_function_of_MD5
gateway.glop.me/ipfs/QmTsmgrWfQD11CTeGU7nqY379MYf2NycQxPmxrTCUixWDa/zkp.py
python zkp.py

>You can test this by using gateway.glop.me/ipfs/QmXj4TBWiokWCYYVj6UwHvwCcULP3UdmwmaLZoLaBLfJq1/md5raw.py

"IS THIS SAFE TO TALK ABOUT?"

github.com/thereal1024/python-md5-collision
github.com/upbit/clone-fastcoll )

you can test the hashes on the proof with crypto/md5.h patchwork.kernel.org/patch/6423361/

I'm not reading your aspie ramblings.
Again, LOL.

Please explain how this was possible

MD5raw('831a81355f15e9513f1aaee402a313e4785d0d7eea5df584fb84a216d698b839ab0cfb26efcec5e79094ae493d79c353c12cdacde1b1dcf9e3414017b3680e18', [0xc7e79d07, 0x41944cd6, 0xba1fa870, 0xe02d503f])
deaddeaddeaddeaddeaddeaddeaddead
MD5raw('fc65b9b5e2981656c0ad4e5962f3ed22c908b2ec2c5a4ae5a442e8900da7faf05ea5b913f5ffe3674e758ab955f16a5b9ce1f7a6ba89bf2d05233ceee2bb1cfc', [0xc0974e7e, 0x78811171, 0x83f5a3cb, 0x2d5a4e86])
deaddeaddeaddeaddeaddeaddeaddead
MD5raw('1e1ed495db2c9f2f090d4475cf24290857859ad23ff2c86adcb493ab4dbefef2260defa5880b18d83358c8635a964a58ef80c954288b031aedd280424f7394a0', [0x935594da, 0x39e88787, 0xe601456c, 0xc48cd364])
00000000000000000000000000000000
MD5raw('95443ad1f92c8b873227350feb0b26ed3b1efc86a1983f3d47363112f4bbb07433f28060f937b8e742abb8e19179268573c29c7e647c21f9b8118eb92c879001', [0xa4ce3da0, 0xcadb2da4, 0x4f10c6f9, 0x3762d5f0])
00000000000000000000000000000000

Please explain how retarded aspies roleplaying makes what possible? Retards who are showing the magic initialization constraints?
Are they pre-imaging md5? No, they admit as much.
You keep claiming they did, but they admit they don't, then they say they're making mad progress, then the autist is on seclists asking for access to a machine with 32GB of RAM and just in general rambling.

Fuck off, moron. Feel free to continue reading the aspie mailing list if you want. But please, stop killing my fucking brain cells by copying and pasting their rambling here.
It's worse than shitposters, at least shitposters know that their shit stinks.

Those are MD5 preimages you idiot. You can simply change the magic values to the default ones and preimage so that it matches md5sum.

No, they fucking aren't.
Stop posting your aspie roleplaying mailing list adventures, please.

If you don't understand how you can turn a pseudo-preimage into a preimage you are admitting that you don't know what the fuck you are talking about.

Well, gee whiz, the super smart aspies roleplaying over bitmessage couldn't do it for me, so I guess they don't have jack shit.

Your first mistake was taking people seriously who are basically guiding you through magic numbers, used OpenSSL for a few minutes and then rambled about magic numbers and deriving the key from information that is used to construct the key.

Instead of a stream of consciousness, it's a stream of autism. One long stream of autism. Kind of entertaining, but you have to take some ibuprofen after reading it for too long.

I actually ran the code and it works. You're the one rambling here. If you don't understand it don't post.

Yeah, no shit, it's a cutdown version of md5.py, with some autism squiggles after the md5rounds.
Can you find a message that has a specific hash value of 3e4fd5b4966caab07cf6324c6fa20ca8?
No? Then fuck off, aspie.

You can test those hashes with any implementation of md5 you want. Here's one from Rivest himself.
people.csail.mit.edu/rivest/Md5.c

No, I want a message that gives me the specific hash value of 3e4fd5b4966caab07cf6324c6fa20ca8.
Please, give it to me. Because, as you say, they've preimaged md5.

I'll post the preimage of this but you have to promise you will admit you are a clueless idiot and never post again

Hurry up I already have your stupid preimage.

I want the message that gives me that specific hash value.

I have it. Agree to never post again if I post it.

Can't promise much, it's pretty easy.
Do that and 3445eabff8a3f2fdf8e87fc5bb48fd43 and I'll never post again, sure aspie.

youareafaggot

echo -n "youareafaggot" | md5sum
3e4fd5b4966caab07cf6324c6fa20ca8

Yeah, no shit.

Still no luck with 3445eabff8a3f2fdf8e87fc5bb48fd43 huh?
Wonder why that is.

Fucking butthurt piece of shit

...

The only asshurt here is from some faggot who unironically reads autists obsessing over magic numbers without knowing what they actually are.
The OpenSSL post above was just embarassing in hindsight.
Why can't you produce the message for 3445eabff8a3f2fdf8e87fc5bb48fd43 ?

...

Guess the bitmessage autists are posting in the thread. No wonder this board is filled with fucking retards.
Produce the message. It's actually easy, it's low bytes, but random: 3445eabff8a3f2fdf8e87fc5bb48fd43

So, yeah. Autists can go back to bitmessage now.

why are you pretending why are you saging and running away?

'youareafaggot' would be my second guess.
An attempt at humor, really.
You can't produce the message for 3445eabff8a3f2fdf8e87fc5bb48fd43 because there is no attack, simple as that.
Hell, I'll give you another maymay as a freebie:
fc5e84e20804e20a060dab71671d7d10

You can't produce either of these, because there is no attack. it's autists on bitmessage being autists.

you fucking retard. it would take forever for someone to try all their 'guesses' to match that hash with no clues. admit that you got butt blasted and leave.

Do you even know the context of this conversation, you fucking retard?
Wow, you mean a brute force attack?
No shit, faggot.
The point is that they have nothing.

...

...

You guessed a very easy message. It was an attempt at humor, but it seems to have been lost on you because you're severely autistic.
You can't produce messages for the two hashes I've given, because there is no attack.

The point is that: 1) md5 is fine for the KDF in the way it was being used. Could use a new KDF, sure, but there's nothing really gained from changing the message digest manually for encrypt. 2) there is no attack, and it's a bunch of fucking morons on bitmessage roleplaying.

If you can't produce the messages in a few seconds with the magical program that the bitmessage autists gave you, then there's no attack. Right?

this isn't about you retard. you already got the proof you asked for. read the fucking posts. if you don't understand them leave the thread and shut the fuck up.

lmao
Produce the messages. If you can't produce the messages for those two hashes, you're wrong.

6 minutes

Explain how IN THE HOLY FUCK can someone read your shitty post get the preimage and post it in 6 minutes. If you are going to claim that the poster guessed it you are admitting that you are retarded.

Because it's on google, no rainbow table even needed.
google.com/#q="3e4fd5b4966caab07cf6324c6fa20ca8"
lmao

Bitmessage autists deserve to have a joke made out of them. The fact that it took six minutes is pretty funny.

i hate posting on these sites but this is just bullshit stupidity or paid posting.
is impossible to fake. any of you crypto posers that don't understand what those hashes mean can feel free to create another combination of values that produces deaddeaddeaddeaddeaddeaddeaddead or 00000000000000000000000000000000. if you can't I suggest you let these people explain this before it has never been done before.

Those values do not produce either.
echo -n "831a81355f15e9513f1aaee402a313e4785d0d7eea5df584fb84a216d698b839ab0cfb26efcec5e79094ae493d79c353c12cdacde1b1dcf9e3414017b3680e18" | md5sum
77bced5ee855b133ae6e8063dc15aa8d -

You are a fucking retard.

you have to use the IV values. I tried with and starship.python.net/~gherman/programs/md5py/md5py.py and they work. if you think they are fake then produces another list of values that make those digests.

long known
THIS
No need--OpenSSL already has some indication of correct decryption--this is where "bad decrypt" comes from if you use the wrong key.
In this case, no KDF is used because you set the key directly. The salt is only used with the KDF, so it is useless in this case. Note that the encrypted files lack the "Salted" header and these "salts" are not actually written to the ciphertext file. This is an information leak--the presence of a salt in the encrypted file indicates the use of OpenSSL's KDF.
Only points 7, 8, 13 are unhelpful. The rest are good. Point 13 is flat-out wrong.
The most probable information leaks are the salt and the initialization vector. The key is fully determined by the salt and the passphrase.

The weird salts varying is probably related to ASLR and/or prelinking. The weird garbage salts only occur when the KDF is not used, which means that the weird salts have no effect on the ciphertext.

This is yet another red herring--OpenSSL tries to use the RDRAND instruction, which Valgrind does not support. File a bug report on Valgrind, mention the instruction sequence 0x48 0xF 0xC7 0xF0 0x72. Your disassembler does not recognize RDRAND either.

The OpenSSL ENGINE module is a pluggable interface for cryptographic accelerators or smartcards.

OpenSSL is highly modular--CRYPTO_malloc can be replaced by the client program.

Macros like "osslargused" are common in code bases that are scanned for common programming errors; they suppress warnings about unused arguments. The "file" and "line" arguments are for the debugging code that you aren't using in your build. "(void)46;" does precisely nothing, since it casts a side-effect-free expression to void. An optimizing compiler should discard the entire statement. The cast to void prevents the compiler from warning about useless code.

It's for a debugging aid--look at the pile of crap that OPENSSL_NO_CRYPTO_MDEBUG excludes and you'll see what those are used for. In terms of information leaks, it's a red herring--it would only leak information about OpenSSL's own source code.

That would be a smoking gun if you find it.

The "VOID" does not exist--those lines are there to supress warnings about "file" and "line" being unused if debugging is turned off. The compiler ignores them. Some lint(1) is fooled by them. The name "ossl" is probably a good hint at what they fool.

I'll say this again: The salt and IV are possible side-channels to leak the passphrase and/or the AES key. The "VOID" would be compiler bugs and would get fixed.

Are you fucking retarded?

why are people acting like this is impossible. this was just the TAO for encrypted files. heartbleed was the TAO for online SSL.

Because we're not a bunch of fucking retards circlejerking on bitmessage channels and begging for a pitiful 32GB of ram on the seclists mailing list.
I'll ask again: are you fucking retarded?

NO! C actually specifies very little about memory--the C standard does not NOT require the flat address space we all take for granted on PCs. Those comments complain that there is no good way to determine if two buffers overlap, because a pointer derived from buffer A may not even be in the same address space as a pointer derived from buffer B.
Maybe, maybe not--the comment suggests that the purpose of rand_add is to add "buf" to the entropy pool.
This is a more-or-less standard design practice--Yarrow does it, Fortuna does it, the Linux kernel RNG does it. Not doing this is yet another indictment of OpenSSL's code quality if anything.

All said--if there is any fire here, it'll be in the RNG somehow.

How does it shut up compiler warnings, exactly? Both "line" and "file" are used in the function, so they aren't unused parameters at all.

"line" and "file" in the function.

if (malloc_impl != NULL && malloc_impl != CRYPTO_malloc)
return malloc_impl(num, file, line);

Sorry, on whatever mailing list was aggregated by seclists. I saw one of you retards doing that.
Also the retard posted it to the Firefox bug reports first, hilariously. Maybe the faggot is just schizophrenic. Who knows?

>Additionally, as a reference, here is the commit that introduced Heartbleed git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4817504d069b4c5082161b02a22116ad75f822b1
github.com/openssl/openssl/commit/96db9023b881d7cd9f379b0c154650d6c108e9a3

github.com/guidovranken/openssl-x509-vulnerabilities
seclists.org/fulldisclosure/2016/Oct/62
There are many other instances of double frees in the code.

Which files don't have Salted in the header?

You are both correct and incorrect--the compiler will probably not warn, since the arguments are mentioned. There is probably some lint(1) tool that will complain if any path through the function exists where those parameters are unused. And such a path does exist--if the call is not forwarded through *malloc_impl, those parameters are unused, since malloc(3) doesn't take file and line for calling code.

This is really another bit of OpenSSL devs being ignorant--every funciton call gets a return address, which can be translated (see addr2line(1)) back to file and line. There is no need to pass the caller's location as explicit parameters.

The files that were produced by specifying an AES key instead of using a passphrase lack the "Salted" header and the bogus "salt" that OpenSSL reports is not actually written to the file.

openbsd.org/papers/bsdcan14-libressl/mgp00014.html

blogs.rsa.com/rsa-response/
wired.com/2007/11/securitymatters-1115
nist.gov/news-events/news/2014/04/nist-removes-cryptography-algorithm-random-number-generator-recommendations

rump2007.cr.yp.to/15-shumow.pdf

It was removed. What's your point? They implemented it for FIPS compliance, that's how the maintainers made their money. In fact, the build was broken: as far as anyone could tell it never worked and no one used it.

...

do you also think heartbleed was never used and didn't affect anyone?

Heartbleed was a memory safety/buffer length checking issue, and was wide ranging in its effects.
The PRNG we're talking about was implemented solely for FIPS compliance as part of a contract to be, shocker, FIPS compliant, wasn't even enabled on Red Hat based distros (builds which are known to strive for FIPS compliance) and wouldn't even compile. In fact, it probably never compiled.

Aside from yet more indictments of OpenSSL's code quality, this leads to questions about OpenSSL's main RNG. (The one that actually compiles.) The important questions are: does the passphrase somehow get into the entropy pool before the salt or IV is generated and does the AES key somehow get into the entropy pool before the IV is generated? These are both as insane as they sound and not as unexpected as they should be--OpenSSL has been caught directly seeding the RNG with bits from the user's RSA private key in the past.

If this is a TAO backdoor, expect the eventual attack to narrow the search space for the AES key to 30 to 50 bits, after about 2^50 to 2^70 one-time precomputation to solve the RNG. If this is "OpenSSL devs are idiots", the eventual attack may be as little as 2^10 or less.
>"No one thought about trying that before..."

Why are you talking about FIPS. All these vulnerabilities are on the regular version of OpenSSL. was an example of what these backdoors look like since it's one of the few ones that is publicly known.

Decompile with IDA and see. It's there. This is not incompetence. They did a really good job at hiding it. It's pure TAO and was mentioned in Snowden's leaks.

The maintainers made their pitiful money through contracts to make the regular version of OpenSSL FIPS compliant.
It's not much of a backdoor if no one used it and it never compiled, is it champ?

You've already been fucking told that your disassembler does not support the instructions.
How fucking stupid are you?

OpenSSL is not FIPS compliant unless you change to 'FIPS mode'.

openssl.org/docs/fipsnotes.html

$ openssl md5 somefile
$ openssl sha1 somefile

Stop googling things and then pretending to understand them. MD5 is not FIPS compliant itself and OpenSSL makes it's keys using ONLY MD5. Stop embarrassing yourself for fucks sake.

No, it does not. You've always been able to change the message digest.
The only one who's embarassing themselves as you.
It was implemented for FIPS compliance, not STRINGENT FIPS compliance, but that's why it was implemented. Someone fucking paid them to do it. They included it in the source tree. It didn't work, and as far as anyone can tell no one used it.

Again, it's just embarassing that it needs to be explained how to change the message digest.
And, it doesn't even fucking matter in this KDF. As long as preimage resistance is sound, there's nothing wrong with this KDF. Okay, faggot?

And further, just fuck off back to your bitmessage channels. I'm tired of reading asshurt from assburgers who are being blown the fuck out after you retards roleplayed and shit up every imageboard with your copypasta, then some faggots posted it to reddit and HN and you got laughed at. And you're still being laughed at, in this thread.
Fuck off, retard. You want to do some actual work, that's fine, but don't pretend you're uncovering some super secret "TAO conspiracy". You're not even using the right nomenclature, for fucks sake, the actual program is BULLRUN and associated ECI labels, TAO is a "cyber-warfare" unit and involves infiltrating foreign entities through various means.

Ok. I'm going to make a key with OpenSSL's 'KDF'.
openssl enc -aes-256-cbc -p -in test.pdf -out test.aes -salt -k youreanidiot
salt=8473462593B91D56
key=53712BBB694368D9B97BB0374471FEAFFB46F3F0403DA8973B0D4D63FBA41685
iv =866802D09D11DF5627DA154DD12071BC
That's the key I got. Now, I'm going to make that same key using only md5.

perl -e 'print pack "H*", "8473462593B91D56"' > salt
echo -n youreanidiot > keyhalf
cat salt >> keyhalf
==md5sum== keyhalf
53712bbb694368d9b97bb0374471feaf
perl -e 'print pack "H*", "53712BBB694368D9B97BB0374471FEAF"' > key
cat key > keyfull
echo -n youreanidiot > password
cat password >> keyfull
cat salt >> keyfull
==md5sum== keyfull
fb46f3f0403da8973b0d4d63fba41685

53712bbb694368d9b97bb0374471feaffb46f3f0403da8973b0d4d63fba41685
53712BBB694368D9B97BB0374471FEAFFB46F3F0403DA8973B0D4D63FBA41685

If it doesn't only use MD5 why can I recreate the key from a command line using only md5sum?

Here, educate yourself:
edwardsnowden.com/wp-content/uploads/2013/10/project-bullrun-classification-guide.pdf

Brave proclamation.
There's nothing wrong with this, because the salts are not written to the ciphertext header.
You must be fucking brain damaged.
I'm doing just fine, retard.
BULLRUN is the word you're looking for: "to covertly introduce weaknesses into the encryption standards followed by hardware and software developers around the world."

Once, again, you've just embarassed yourself.
Crawl back to bitmessage, then come back when you're not a total cocksucking faggot.

You just said it didn't only use MD5 and I proved to you it does.
There is no searchable text in that document. Try reading it.

openssl chooses the salts for you and it's not random. i did the tests in the copy pasta and got the same results.

Try the -md flag, you cocksucking retard.
You're right, but TAO is a partner, and it's only to leverage "specific computer network exploitation activities" of TAO. TAO specializes in foreign network or foreign target intrusion. It has nothing to do with what your silly imagination is implying here.

So, again, you've embarassed yourself.
Stop posting, please. For your sake. Back to bitmessage so you can continue roleplaying.

The salts are not written to the ciphertext, so this does not matter.
Are you retards seriously this fucking stupid?

theres one teenager or shill (can't tell) posting blatantly stupid things. it seems like its only one person tho. i doubt that someone would be this stupid so i think its just someone trying to turn the thread into namecalling.

the key is made with the salt. it doesn't matter what it's in the ciphertext. if you have the key you can read it.

WOW, ENCRYPTION BACKDOOR ALERT
IF YOU HAVE THE KEY, YOU CAN READ IT.
What a stunning revelation. Front page of The Intercept coming through. Backdoor confirmed.
Stop posting, please.

if you're so confident that there's nothing wrong why don't you use their RND function to generate a couple hundred thousand numbers and then analyze the entropy. I don't mean google that and then copy paste the first you thing you saw that you think is an argument. I mean actually run the code in the library and post real results someone can recreate.

ATTENTION, TO ALL THOSE WHO WILL LISTEN.
I HAVE DISCOVERED A MAJOR BACKDOOR IN OPENSSL.
DEMONSTRATION IS AS FOLLOWS:

$ openssl enc -aes-256-cbc -md sha256 -p -in project-bullrun-classification-guide.pdf -out bullrun.aes -salt -k youareacocksuckingretard
salt=E130827539D0F542
key=09100A317A45DB7C14524A47553131AD56FBC4D1446A8B03A2C9B40C918DCA12
iv =3C4A388A475D35C8C01613E3FB9B7EA3

THAT'S THE KEY I GOT. NOW WATCH, AS I CONSTRUCT THE KEY FROM THESE CCCCCRRRRAAAAZZZZYYYYY NUMBERS THAT OPENSSL SPITS OUT. WHAT DO THEY MEAN?
WHO THE FUCK KNOWS. WE'VE GOT BIGGER PROBLEMS. THE "IV" "NUMBER" MAY BE AN NSA CALLING CARD BACK TO TAO HOME BASE. NO WAY TO TELL, WE CAN ONLY ASSUME THE WORST.

$ perl -e 'print pack "H*", "E130827539D0F542"' > salt
$ echo -n youareacocksuckingretard > keyhalf
$ cat salt >> keyhalf
NOSCOPED:
$ sha256sum keyhalf
09100a317a45db7c14524a47553131ad56fbc4d1446a8b03a2c9b40c918dca12 keyhalf

BACKDOOR CONFIRMED. SHA-256 PREIMAGED. ILLUMINATI EXPOSED.

NOW THAT YOU KNOW WHAT THIS MEANS, BE CAREFUL WITH IT. BE RESPONSIBLE. TRUST NO 1.
IF YOU DON'T KNOW WHAT THIS MEANS, PLEASE FUCK OFF BACK TO REDDIT TBH. GETTIN REAL TIRED OF YOUR SHIT.

Stop posting, and go back to bitmessage.

The KDF is too fast, but it is also very old. The primary issue here is the question of what exactly goes into the entropy pool that produces the salt and the IV. If the IV is derived from the key, game over. If the salt is derived from the passphrase, game over.

Accurate or not, "TAO" has become a general term for "NSA fuckery".

WRONG!
If a passphrase is used, the salt must be stored with the ciphertext, otherwise, it would not be possible to regenerate the key, even with same passphrase. AES_key = KDF(salt, passphrase)
If an AES key is directly specified, instead of using a passphrase, then AES_key = key and there is no salt and OpenSSL reports a bogus value for the "salt". This is probably an unrelated bug.

How's the weather in Ft. Meade, shill?

You know full damn well that's not what we're taking about. The issue is how exactly OpenSSL produces the salt and the initialization_vector and if those in any way depend on the actual AES key or passphrase.

It's equal to secondkeyhalf || password || salt

$ openssl enc -aes-256-cbc -k PASSWORD -p -P
salt=07D958292CBA3A42
key=D2C14511FB2ED4F492E64FC94F768FE72FF0E93767FE936B40A76842D058ADB5
iv =2ED7B3C55389C4BAE9B947C1C945DA1B

secondkeyhalf || password || salt
2FF0E93767FE936B40A76842D058ADB5 || 50415353574F5244 || 07D958292CBA3A42
2FF0E93767FE936B40A76842D058ADB550415353574F524407D958292CBA3A42

$ echo -n 2FF0E93767FE936B40A76842D058ADB550415353574F524407D958292CBA3A42 | xxd -p -r | md5sum
2ed7b3c55389c4bae9b947c1c945da1b -
iv =2ED7B3C55389C4BAE9B947C1C945DA1B

You're right, I was trying to figure out what the fuck the retard I was responding to was talking about.
Then I wrote
There's nothing wrong with this KDF. In fact, you shouldn't even be entering the encryption password as an argument, because it's recorded in bash history.

Yeah, it is you fucking moron. Read the documentation. There's nothing wrong with this KDF. Why are you spending weeks shitposting on bitmessage with something that can be answered in two minutes by reading the enc documentation?

Also
openssl.org/docs/apps/enc.html
WOW THIS SURE WAS FUCKING HARD.

FULLY PUBLIC NSA BACKDOOR. ILLUMINATI EXPOSED.

Fuck I hate retards.

That's a runtime flag to set the IV manually. Again, googling things without understanding them. This is what you're looking for.
github.com/openssl/openssl/blob/master/crypto/evp/evp_enc.c

Okay fucktard, are you unable to read:
When you specify an ACTUAL KEY, you must specify the IV directly.

Learn to fucking read. It was right there in the text, jackass.

I'm out of this thread, because it's filled with fucking morons from the bitmessage channels that are obviously drooling aspergers who don't know what the fuck they're talking about and can't read documentation.

People here are reading the code, not the documentation. That's why you don't understand what's going on.

If you're unable to fucking understand that the initialization vector generation, when only a password specified, is not in that file but in EVP_BytesToKey, then you're incompetent and your opinion amounts to less than dogshit. Stop posting, and go back to bitmessage, you subhuman retard.

And what does EVP_BytesToKey do to generate it?

Why don't you fucking read the code yourself, subhuman. I'm not spoonfeeding you any longer.

This is both very well documented and easily accessible to anyone who understands C. You fucking read the documentation, that you obviously missed, and read EVP_BytesToKey, and then you go back to roleplaying about how you know how to use IDA on BitMessage, because this shit is just fucking embarassing.

I already posted how it does it here

Why are you posting in a thread that you think is a waste of time? Why not just ignore it?

I already posted how it's documented and what the function is, you were talking about how the IV is generated.
Now obviously you're just mentally retarded or can't follow the conversation, so I'm actually going to go.
It is quite a waste of time now that I've probed the fact that you're a sub-100 IQ nigger, yes.

Anyways, there's nothing here to anyone who's not interested in reading the rambling of retards who "know how to disassemble" (lol) on bitmessage.

It isn't documented. That's why you posted a link to the IV runtime flag.

Paste expired, dipshit.

Yes, it is. It's PKCS#5 v1.5
wiki.openssl.org/index.php/Manual:EVP_BytesToKey(3)
For CBC based encryption, it derives the IV and KEY from the password+salt.
This is just old, enc exists before PKCS #5 v2.0
en.wikipedia.org/wiki/PBKDF2

This thread is pretty funny.

'count' is set to ===1=== and can't be changed. Therefore what actually happens is

'data' is the password and 'D_(i-1)' is nothing or a part of the key.

This means means
keyhalf = HASH(password || salt)
keyhalf2 = HASH(keyhalf || password || salt)
IV = HASH(keyhalf2 || password || salt)

That's why you should be reading the actual code instead of trusting google blindly.

No, it doesn't, and at this point you're just making a laughingstalk out of yourself. It's PKCS#5 v1.5.
github.com/openssl/openssl/blob/master/apps/enc.c
Apparently you were so incompetent that you couldn't even find the correct point where it began.

So, yeah, your opinion really isn't worth anything.

Also, github.com/openssl/openssl/blob/master/crypto/evp/evp_key.c

Again, this thread is funny.

If was not true then the output of and would be different from what openssl produces.

If you're going to stay at least get off your shitty windows vidya computer and try running these commands yourself.

...
...
...
If that documentation is accurate then the OpenSSL devs are confirmed for 1000% retards. How the fucking fuckity fuck fuck do you think that generating public information (the IV) from secret information (the FUCKING PASSPHRASE) is OK?

FUCKING FUCKITY FUCK-FUCK! It's right there in the C code. Instead of a random IV, the initialization vector is derived from the passphrase!

...
...
...
OH WAIT--THE WHOLE DAMN THING IS A FUCKING RED HERRING BECAUSE OPENSSL CAN'T INTO BEST PRACTICES
The IV is not included in the ciphertext, never mind that CBC requires a nonce IV for security, which would be included with the ciphertext. en.wikipedia.org/wiki/Initialization_vector

It's not as bad as it could be, but the takeaway is:
OpenSSL enc(1) can reuse initialization vectors
This should be mitigated by the use of a salt value, so that even if the same key is used for multiple messages, the actual AES key and IV will be different. Unless, of course, you have an ancient version that didn't use salts or you just so happen to have the "special" OpenSSL that reliably produces the same salt for the same passphrase...

OK... one smoke cloud left... does the RNG have the passphrase in the entropy pool when it generates the salt? The salt is the only remaining potential information leak. It's 64 bits, probably enough to severely weaken an English passphrase.

The satl/key/IV thing is not even part of the smoke. That's just what shills latch onto because it's the only thing that they can defend by using google links and never looking at the actual code. I expect that this will be the limited hangout for this issue. Even if you stop here you can already break the encryption of a file created with openssl by downloading a sat solver from github and using a decent computer. However, that doesn't matter because the real issue is much bigger and has multiple components.

Remember that count is set to 1 and can't be changed.

Yes but the salt is not random. That is part of the problem. It does go into the 'entropy' pool. There are also double frees and multiple padding oracles. You can easily find these problems because the code has comments and commit messages pointing them out, possibly by disgruntled employees that were forced to put them there and wanted to save face.
ghostbin.com/paste/xqtea
Try it yourself. Generate a lot of salts and verify if they are random.

What you are looking at is the offline version of Heartbleed. It is a known fact that Heartbleed was not a random 'bug' and was, at the very least, allowed to be there and used by NSA and GCHQ. When Heartbleed was 'patched' you would expect someone to have gone through the entire codebase and fixed all other issues. Somehow this never happened and a lot of people quietly moved to LibreSSL.

Now, put it in perspective. Heartbleed was 'found' after Snowden's leaks, which were never really published and included low level details about TAO strategies.

twitter.com/snowden/status/776536497419943940?lang=en

Here is the commit that introduced Heartbleed: git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4817504d069b4c5082161b02a22116ad75f822b1

Just skim that commit and if you know anything about code you will see that it is an obvious addition of a backdoor to the user's memory. They even directly tell you in the comments.

Here is the commit that 'patched' it:
github.com/openssl/openssl/commit/96db9023b881d7cd9f379b0c154650d6c108e9a3

git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4817504d069b4c5082161b02a22116ad75f822b1

en.wikipedia.org/wiki/Heartbleed

bloomberg.com/news/articles/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers

Finally, the only way to avoid heartbleed was to compile with DOPENSSL_NO_HEARTBEATS.

Don't take my word for it. Just run the code with valgrind and see what happens when you encrypt/decrypt. Decompile it and see what is actually being done. Test the randomness. Make an AST from the code. Count the number of double frees that are taking place. Compare their function to LibreSSL's. See what extra procedures only happen in OpenSSL. The evidence is there.

This has to be addressed immediately and everyone has to be warned to re-encrypt their offline data with actual encryption.

No, that's just a problem with C's lack of bounds checking sanity.
It's not an intentional backdoor, you're just fucking stupid. Heartbeats in TLS are a valid thing, if overengineered.

Again, you don't know what you're talking about.

Yeah, the same stupid sperg bullshitting on bitmessage.
Listen dipshit, you don't have a bug here, you don't even have a backdoor.
You're probably schizophrenic, what with your "group" of obviously mentally deficient retards jumping between various examples, pretending they "preimaged" md5, saying that it's not random because they disassembled openssl.

You do not know what you're talking about.

Stop bumping your shit thread. No one needs to hear your retardation. If you want to roleplay, go to Holla Forums. They're much easier to convince of stupid shit.

Randomly insulting people online is not going to get you anywhere. If you want to make a point post evidence of the code doing what it's supposed to in a way that can be recreated by others. The people that are worried about this issue have gone out of their way to give people like you simple examples they can recreate quickly to see that there are real problems here. You have not provided a single bit of evidence of any kind and have only posted insults and multiple claims that you will leave.

You are supposed to do the bound checks. It's the first thing they teach you.

post your 'disassembled' code showing it is random

Declaring from the former that there's a backdoor and not understanding how PKCS#5 v1.5 works means that your "concern" is not worth anything.

Evidence has already been linked in the thread. It works how the documentation suggests, the code is right there, apps/enc.c has been linked, everything else relevant has been linked (note, this retard linked something totally irrelevant in the context of the discussion, so I can only assume that you faggots are incompetent.)

You couldn't even find EVP_BytesToKey, despite it being explicitly documented.

Your opinions on what is and isn't problematic are not worth anything.

tl;dr, there's nothing wrong with the way OpenSSL encrypts. It's old, and certainly needs something more modern when it comes to passwords, but this isn't a backdoor, and it's not even a bug, especially for compatibility.

As has been said: PKCS#5 v1.5

As has been said, you do not know how your disassembler works, and the fact that you could not find the function or the documentation suggests that you are incompetent.
Try putting down the disassembler until you understand what you're doing. Because you clearly do not.

C is a razor, the vast majority of bugs come from wielding it. This isn't relevant to the discussion at all.
Again, if you want to roleplay, go try Holla Forums. Remember to keep them up to date on all your epic finds on bitmessage, I'm sure they will appreciate it. Do that, and stop shitting up the board please.

sorry but im starting to think that you are a shill. you are saying these posters dont understand evp_bytestokey but they reproduced its results from the command line and proved that it does not work like it says in the documentation. if you dont have anything to add please leave. linking to openssl wiki pages is not evidence of anything.

There's been no evidence to suggest that it works any different from the documentation. The relevant files have all been linked, that's how it works.
Unless you want to walk me through your obvious mastery in C, what with pretending that your disassembler supports that specific instruction, you have presented zero evidence to the contrary.
Thus, the burden is on you, and not on anyone else.
It works exactly how it says in the documentation. It's one iteration, key+IV.

The best case scenario here is brute forcing passwords. If your task is to recover the encrypted data, you must discover the key+IV.

The only problem with this implementation is that it's iterations are hard coded to one, but again it's old.
Nah, I think it's time for you to go back to whatever discussion forum you came from.

This is why the KDF is too fast, but this is also a very old KDF. This was acceptable then, but it makes brute-force searches too easy now.
Padding oracles are useless in offline attacks--read en.wikipedia.org/wiki/Padding_oracle_attack
A padding oracle allows an attacker to decrypt data with the oracle's key without knowing the key.
Because the OpenSSL devs had proved yet again that they have no clue how to write secure cryptographic software.

I've never used OpenSSL enc(1) for much, only for the purpose for which it almost seems tailor-made: wrapping key material for transport. (Encrypt the key and send the wrapping key by a different channel. Recipient decrypts the key and installs it.) It should be obvious that is a very attractive place to put a backdoor...

The salt is part of the smoke--it is the only value placed in cleartext in an OpenSSL encrypted blob. I've since found that the IV is derived from the passphrase and not actually included with the ciphertext. There isn't much left here--an attacker only has the ciphertext, which is the encrypted blob, a magic number "Salted__" and a 64 bit salt.

Please give step-by-step how to break an OpenSSL blob using only the salt, the ciphertext, and a sat solver. I did not think the efforts were this far along yet. I thought that the RNG still needed to be traced--it's the only path for the passphrase to leak to the salt. The allocator weirdness would merely be the means to get the passphrase into the entropy pool--or to simply replace the entropy pool so that the salt is just part of a hash of the passphrase.

Unlike the KDF, which can use a different digest, the RNG is one algorithm. If the salt depends on the passphrase, Eve can speed up a brute-force search by skipping decrypt attempts for guesses that "can't make that salt". Most passphrases probably have shit for entropy.

A test: repeatedly run "openssl enc -aes-256-cbc -pass pass:[email protected]/* */ -p -in example_in -out example_out | grep salt >>salt_log" and check salt_log for duplicates. I've just done a quick test and got 10000 unique salts of 10000 runs. So at least 13 bits of the salt are honest and the salt can't weaken the passphrase by more than 51 bits. At some point you'll start getting duplicate salts simply because there are only so many 64-bit numbers, but you should be able limit the side channel to at most 32 bits or so by this black-box test. The "salt_log" grows by 22 bytes for each entry placed in the file.

It's also possible that variant configurations exist and some are stronger than others. The backdoor may require some activation (likely flipping a single bit in OpenSSL) that TAO knows how to do. The black-box test I've described can limit the reach of a side-channel that affects everyone, but gives no information about a targeted attack not aimed at you. To prove the "just add water" backdoor will require detailed code analysis.

Not useless in offline attacks. See:
ghostbin.com/paste/vf59f
And:

Some discussion on some of the known double frees:
github.com/guidovranken/openssl-x509-vulnerabilities
seclists.org/fulldisclosure/2016/Oct/62

Some hints about the RND problem:
stackoverflow.com/questions/23360694/openssl-ia32-rdrand-cmp-cmove-instructions#23363802

This is enough to cause serious damage. See:
ghostbin.com/paste/azdoo

yeah, that's where the real horrors lie.
openbsd.org/papers/bsdcan14-libressl/mgp00017.html
It's very similar to the RSA issue.

...

That isn't a padding oracle attack. Read the Wikipedia article. A padding oracle attack is a way to trick a system that has the key into decrypting a message for you.
That is a form of differential cryptanalysis, where the same (known) plaintext has been encrypted twice, but AES was not correctly followed for one of the ciphertexts. This type of attack can expose the key, but again, is a way to get a key from a device that already has it, like a smartcard.

THIS
This is the only place that could harbor a backdoor into blobs created with enc(1).

That's nice dear, we get it. It still doesn't change the fact that you retards were wrong about pretty much all specific claims made.
Thinking you're surprising anyone here with "OpenSSL is a mess of hacks and the code quality is poor" is pretty amazing.
The horse is dead.

The incompetence meme is not believable anymore. Billion dollar corporations rely on this software. The whole world was affected by heartattack and all these things are somehow still there.

If you want to claim this horse is dead start by explaining why RND is not random. Start here stackoverflow.com/questions/23360694/openssl-ia32-rdrand-cmp-cmove-instructions#23363802

Saying you're wrong over and over won't do anything in a thread full of data that anyone can recreate in their homes.

en.wikipedia.org/wiki/Padding_oracle_attack
"The attack relies on having a "padding oracle" who freely responds to queries about whether a message is correctly padded or not."
You can check whether the message is padded or not by using using head/tail. Most famous padding oracles rely on remote access but it is not necessary. According to Wikipedia PRISM is a program about collecting 'metadata'. It's better to read scientific papers.

Here's another example of an offline padding oracle:
ghostbin.com/paste/7hgnm

Here's the code:
ghostbin.com/paste/829qq

It's not incompetence, it's just lack of good maintainership.
What the fuck are you talking about, RND? Are you talking about the instruction RdRand? Are you talking about their API that it's referencing that makes the call?
You do realize that the example you're giving has to be explicitly set as the RAND_method, right?

Again, it's a whole bunch of rambling, and you seem to be a total faggot about it all.

Yeah, you were wrong, about pretty much all specific claims.
You're not making a specific claim, btw. You're just shitposting about about the code quality by vomiting quotes.

Hey, I got a great idea. How about, you go to the issue tracker, make some issues, talk with the actual maintainers, maybe even fix some things, and then you wouldn't have so much to bitch about on an anonymous discussion forum, whether or not you're wrong or not in any specific claims.

How about you do that, faggot? How does that sound? Oh, it's more fulfilling to pretend you know what you're talking about and not do any actual work. I guess so.

This what their reaction
openssl.org/news/vulnerabilities.html#y2016
And then
>see github.com/openssl/openssl/pull/2083, which implements PBKDF2 and a better iteration count than 1.
>Richard Levitte [email protected]/* */ OpenSSL Project openssl.org/~levitte/

They don't care and don't want to fix it. Just like you they are focusing and strawmen and ignoring how the randomness and memory is clearly rigged. The same happened with heartbleed. No one cared until someone wrote up the full exploit.

...

so what are you waiting for then

No one is going to write an exploit that unlocks every single file encrypted with openssl

nice try CES

i guess no one is going to care then
thread ogre

You seriously are brain damaged, and have no idea what you're really even talking about.
It's working exactly as intended, there's no "exploit", it's just old. And shitty. If you want to encrypt files via password with OpenSSL, definitely you want it to be very high entropy at least.

Or, hey, you should use GnuPG, like everyone sane. No, this doesn't affect TLS. No, wikileaks doesn't fucking use OpenSSL for encrypting insurance files. Why the fuck would they do that for symmetric encryption when they definitely use GnuPG everywhere else?

Retards making retarded sounds in this thread.

sorry man. not op but if you're going to keep shilling this thread like this you have to be called out.
you have said
-md5 can't be preimaged
-if someone posts a preimage of a shitty hash you'll leave
-openssl flaw is only for a fips implementation that doesn't exist
-openssl doesn't just use md5
-salt does not go into ciphertext
- -iv flag is how IV is set
-heartbleed happened because of a "problem with C's lack of bounds checking sanity"
-PKCS#5 v1.5 = one round of md5(salt+password)

all while posting from a windows 10 computer with multiple reddit and voat tabs open and discords channels and pretending you are 'from' a site you found out about in november while 'investigating' pizzagate from a shitty subreddit where you ran some shitty steg software and now think you are a gnu expert while taking breaks from playing overwatch. you clearly don't care about having been wrong over and over with evidence posted for you every step of the way. you've said you will leave multiple times. do it. if you keep posting you are showing that you for some reason you care a lot about this.

you still have not posted a single thing that isn't some half ass google search. post some code that proofs anything you are saying. if you can't go back to your discord channel.

there's a group that seems to have written the whole exploit. they have a list of members of the cryptography/encryption communities that are willing to speak out about it. this was an organized process until someone started posting random copy pastas everywhere and effectively started a giant shillop of 'it's nothing'. I'm willing to work with a new group that is serious about doing very detailed code analysis but I don't think this site has any people that would care enough to do it.

No, it has been said
Never been said, it's just that you retards are incompetent and don't have anything
You mean the "preimage attack" you googled the hash and posted?
That's correct, it's been sha256 default for a while now, actually. You change it via the message digest. It doesn't really matter, though, because your best case is still brute forcing the password.
Is, when you're using a key directly.
Actually, yeah, Dual_EC_DRBG was never a real OpenSSL flaw.
Again, depending if you're using key directly
Yeah, it did
Yeah, it can be, but this is just what "OpenSSL does".

FRIENDLY REMINDER THAT SHA256 IS BACKDOORED
PROOF IS IN
NSA EXPOSED, SHA256 PREIMAGED

schneier.com/blog/archives/2008/05/random_number_b.html

anonscm.debian.org/viewvc/pkg-openssl/openssl/trunk/rand/md_rand.c?p2=/openssl/trunk/rand/md_rand.c&p1=openssl/trunk/rand/md_rand.c&r1=141&r2=140&view=diff&pathrev=141

plog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html

web.archive.org/web/20080519120435/http://www.milw0rm.com/exploits/5622

what does code analysis have to do with anything if there's an exploit ready?
why are you here if the experts are ready to speak out?
who the fuck are you implying you are that anyone would give a shit about your willingness to do anything?
this entire thread reeks of schizophrenia without operating system development

one allegedly exists. he doesn't have it.
when have you seen an expert speak out about something like that is still around
you posted so you clearly care about what he thinks.
imagining that all anonymous posts with a different opinion to yours are the same person is just as bad

I didn't say he did.
Pretty much every time, that's how they scare everyone into upgrading. And that isn't even what we disagreed about, the post I replied to said the experts were ready to speak out. You don't seem to be following the conversation.
What? What the fuck are you saying? He's implying he's a bigwig leet haxor ready to reverse le protocols and save le day, that's what I'm calling into question.
I didn't do that, at all. I have made three posts in this thread total and now I'm leaving because everyone in here is functionally illiterate and prone to such drastic and confusing misinterpretation of even the simplest concepts that it's doubtful any productive conversation will take place. Jesus fuck, I just wanted to know what the deal was with the keys.

openssl.org/news/cl102.txt

OpenSSL CHANGES
___

Changes between 1.0.2j and 1.0.2k [xx XXX xxxx]

*) Montgomery multiplication may produce incorrect results

There is a carry propagating bug in the Broadwell-specific Montgomery
multiplication procedure that handles input lengths divisible by, but
longer than 256 bits. Analysis suggests that attacks against RSA, DSA
and DH private keys are impossible. This is because the subroutine in
question is not used in operations with the private key itself and an input
of the attacker's direct choice. Otherwise the bug can manifest itself as
transient authentication and key negotiation failures or reproducible
erroneous outcome of public-key operations with specially crafted input.
Among EC algorithms only Brainpool P-512 curves are affected and one
presumably can attack ECDH key negotiation. Impact was not analyzed in
detail, because pre-requisites for attack are considered unlikely. Namely
multiple clients have to choose the curve in question and the server has to
share the private key among them, neither of which is default behaviour.
Even then only clients that chose the curve will be affected.

This issue was publicly reported as transient failures and was not
initially recognized as a security issue. Thanks to Richard Morgan for
providing reproducible case.
(CVE-2016-7055)
[Andy Polyakov]

blog.torproject.org/blog/tor-browser-65-released

Billion dollar corporations also rely on Windows 10. That means nothing.

NO YOU CAN'T UNLESS YOU ALSO HAVE THE KEY
A padding oracle attack relies on a padding oracle that will attempt to decrypt an arbitrary ciphertext using a key that it has and you don't have and will tell you if the padding was correct after the message was decrypted using the key that you don't have but will not simply tell you the plaintext. In an attack against a file encrypted using OpenSSL's enc(1) you don't have a padding oracle because you aren't talking to someone who has the key. If you know someone who has the key and have no ethics, a $5 wrench is probably more useful than all of this.

Damn right I would--if such an exploit exists, we must assume at least some blackhats have it already or they'll have it soon. Knowing that you're fucked is better than thinking that you're safe but really being fucked. If nothing, we're now racing against those blackhats--who will prove the fatal flaw in enc(1) first? The good guys, who will reveal that the emperor's new clothes are NULL? Or the bad guys, who will use the exploit to steal everything they can?

I've seen at least one insurance file that had the "Salted__" header. They've used OpenSSL for some of them.

I agree that it's needed, but I've got too many other irons in the fire right now to help.

Partly correct. The suspicion is that the salt value may give clues about the password. Many passwords probably have shit for entropy and a leak of 10 to 20 bits into the salt would seriously weaken the encrypted blob while being detectable only by careful data-flow analysis of the salt generation process.

There's not anything wrong with that, see PGP's key packet in RFC 4880, S 3.7.1.3:
ietf.org/rfc/rfc4880.txt
$ pgpdump -g bullrun.aesOld: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes) New version(4) Sym alg - AES with 128-bit key(sym 7) Iterated and salted string-to-key(s2k 3): Hash alg - SHA1(hash 2) Salt - \x9b\xe0\xdb8\xad\xb8\x97z Count - 28311552(coded count 235)
The "weakness" in OpenSSL is iterations. Your best case: still brute forcing the password. For something basically from '98-00 and what's a neat little addon for OpenSSL in a pinch, I'm not surprised. Though it's not a backdoor.

LIBRESSL WOOHOO!

Honestly, libressl probably ripped this shit out. Why is it even in there?
There's nothing wrong with it, it's just old, iteration count is fast because shit slow embedded and written in 98, and stayed this way because of compatibility.
I'd think of it as an easter egg for openssl, nothing serious to be relied on, but that's what time does to encryption.

There's nothing wrong with having a random salt. But suppose you have Mallory's special version of GPG that doesn't use a random salt. It hashes the passphrase with MD4 and uses the first n bytes of the hash as the salt. Mallory knows this. Now Mallory doesn't have to attack the full KDF--he can try the MD4 hash of each of his guesses and only run the full KDF (with 28 million iterations) for those guesses that produce the salt he sees that you have used.

The remaining question is where OpenSSL gets the salt from. It's not going to be as obvious as the example I gave above, but if the salt even partially depends on the passphrase, we've got a big problem.

You keep harping on the OpenSSL PRNG just because some fucking retard doesn't know how to use a disassmbler.
Wrong
Holy shit, retard, read the S2K right above in the RFC I linked you.
I'm not going to play spoonfeed the retard here, it's clearly documented and it's a random salt. It's much like PGP's symmetric, and no wonder because although OpenSSL is nonstandard it shares history with a standard described above. Learn to read the fucking files, and the documentation, moron. They're all linked.

So, to end this thread, this is much ado about nothing. The bitmessage channel is hilarious, almost schizophrenic roleplaying, and filled with tards who don't even know what TAO is.

No, you really don't. You're making a big problem, despite it being carefully stated multiple times in this thread, and from the developers themselves, that it's much ado about a very old and neglected function that's more of an addon/demonstration to OpenSSL than it's main function.

But, there's not anything too bad about it for it to be removed entirely. Improving it with a more modern KDF is entirely acceptable, and is being discussed on their issue tracker (additionally discussed is whether some magic bits should be added first, which would be substantially better than the current situation, because compatibility is going to be broken anyways.)

English, do ya speak it?

Using part of MD4(passphrase) as the salt was an example of a BACKDOOR in an evil implementation ("Mallory's special version") that must interoperate with honest implementations.

I'll repeat, since you apparently don't understand: If the salt depends in any way on the passphrase, then we've got a big problem. It doesn't need to be glaringly obvious like salt = MD4(passphrase) would be. And, if the public OpenSSL sources are backdoored, it couldn't be that obvious--the salt must depend on more than just the passphrase. I've proven that the salt has at least 13 bits of entropy already.

THE KDF IS A RED HERRING
THE RNG IS SUSPECT
LEARN TO READ ENGLISH
I PITY DA FOO

Tampered RNGs are a known trick of TAO/BULLRUN/whatever-the-fuck-NSA-calls-it-this-month to weaken security. The RNG in OpenSSL is under suspicion, in part due to the bizarre memory management in the OpenSSL library. See: blog.cr.yp.to/20140205-entropy.html

The salt is a random salt produced by a PRNG seeded by urandom. It's not complicated, faggot.
Yeah, and so was everything else until you retards got told. PRNGs are complicated. If you want to go bitch about them, that's fine, but don't pretend you were right about anything.

diassamble it yourself and show how they did it incorrectly

it isn't and you can prove it easily. there's evidence all over this thread.

the documentation clearly doesn't matter. the posters here have shown multiple times how the code doesn't do what they say it does.

do you also think there was nothing wrong with them using bad seeds for RSA?
groups.google.com/forum/#!topic/mailing.openssl.dev/fpnieXRtEYo

bugs.debian.org/cgi-bin/bugreport.cgi?bug=742145

That's the correct implementation. But OpenSSL has been caught seeding the PRNG with things other than urandom before. The concern is whether the PRNG is being partially seeded with the passphrase.

Don't assume I'm part of the bitmessage tinfoil brigade. I've held this same position the entire thread--the only actual accusation in OP was that the salt is derived from the passphrase and that this data flow is obfuscated. I've never said that it is nor that it isn't. I don't know. You don't know. OpenSSL is a tangled mess and we both know that. It's possible that on my box OpenSSL only uses urandom to seed the PRNG for the salt, but under some other circumstances the passphrase gets mixed in.

I initially considered both the salt and IV as potential side channels, since I understand that IVs should be public nonces. It turns out that OpenSSL doesn't use a nonce IV, instead deriving a secret IV alongside the key. On this, I stand corrected.

If you want to make absolute statements, the burden of proof falls on you. Prove that the OpenSSL PRNG is only seeded from urandom. Hint: we already know that OpenSSL can use RDRAND and RDRAND is not urandom. We know how urandom works. RDRAND is a fucking black box--a fucking malleable black box, since it's implemented in Intel's microcode.

Show where it's seeding with the passphrase, you fucking imbecile. You can't just say "it seeds with the passphrase" and be "concerned" about it, based on nothing but your own insinuations.
The API has been linked. The internal API has been linked. The S2K and encryption functions have been linked.

You're just feeding schizophrenic retards who do not know what they're talking about. Safe to say that you're just a dumb faggot as well. Unless you think it's hilarious, egging on the mentally ill, and indeed it is, which could be forgiven.
No, faggot, it's all been linked. The burden lies on YOU. It's not my fault you can't read fucking C. Not to mention, the claim has been made by you that it's implemented contrary to the documentation.
It's your burden, not mine. Again, it's not my fault that you're an illiterate and can't figure out the project and function structure. For that matter, it has already been linked in this thread, several times.

Fuck off.

Yes, it does do what it says it does, it's just that you're a fucking moron and believed another moron

The shitposting is not even clever, it's just retarded.

Stop putting words in my mouth, shill.
I never said that. I have said repeatedly that that is the only valid claim that OP made. I don't know if it is true. I don't know if it is false. You don't know either.

Those are for PGP, we are talking about OpenSSL enc(1). Do you understand that PGP and OpenSSL are two different things?

I'm not the one making absolute statements. I've said repeatedly that if there is a backdoor in OpenSSL enc(1), it must be in the RNG. You are saying over and over that there is absolutely no possible backdoor and calling me a retard.

I can read C code. I can fucking write C code that doesn't have even half the problems OpenSSL is littered with. No, I'm not going to link any of it--I don't feel like doxing myself today, shill.

What documentation? Cite documentation for the internals of the OpenSSL RNG, please.
WHERE DOES THE DOCUMENTATION DESCRIBE HOW THE "RANDOM" SALT IS GENERATED?

Or is CTR shilling Holla Forums now? You shills really think it'll work any better than it did on Holla Forums?

sounds more like endchan schizophrenic morons tbh

You are fucking retarded.
github.com/openssl/openssl/blob/master/apps/enc.c#L381-L398
IF ENC AND IF THE HEX SALT IS NOT MANUALLY SPECIFIED, RAND_BYTES IS CALLED
Also see mta.openssl.org/pipermail/openssl-commits/2015-March/000788.html
I very much doubt that, retard.
github.com/openssl/openssl/blob/master/doc/man3/RAND_bytes.pod
github.com/openssl/openssl/blob/master/crypto/rand/md_rand.c#L278
definitively NOT seeding with the password, but it's not seeding from urandom. I was probably thinking of the rumblings I heard with urandom/arc4random on platforms which support it.
github.com/openssl/openssl/issues/898

Specifically, they want to make RAND_sys_bytes a part of their API.

You're either schizophrenic, roleplaying, or brain dead fucking stupid. Maybe all three.

Yes, you are.

Do you really think insulting me is going to do anything other than convince anyone reading this that you're a shill?

Does the documentation specify how RAND_bytes produces "random" bytes? Or does it just say "random"?

What was that meme? ... Ah yes ...
>50 cents has been deposited into your account

Do you really think repeating "I CAN READ C" over and over again, despite being unable to read the several functions I just linked, especially the RAND_bytes function, is convincing anyone of anything?

I said that exactly once in this thread, in response to your assertion otherwise. RAND_bytes uses an entropy pool. How is that pool seeded? That's another part of the library.
You're the one harping about documentation.

And the OpenSSL sources are a convoluted mess. The claims in OP were that the sleight-of-hand that puts the passphrase into the entropy pool isn't even in the source, but would require run-time data-flow analysis to uncover. I don't have time to do this myself, so I'm trying to push the tinfoilers to run this down.

Your tactics and argumentation reek of pilpul. Go back to whatever hellhole you crawled from, shill.

No, you're making it pretty apparent that you are incompetent now.
It's right in the same source file, jackass.

And even if you were correct, seeding the entropy pool with a high entropy password is non-recoverable. They do not seed it with the password, but that doesn't mean that a password is recoverable at all. No doubt, because you're fucking retarded.
Nice meme, keep memeing hard friend. Maybe one day you'll be able to read a pitiful hundred lines of C and understand it instead of "speculating" i.e. shitposting on an anonymous imageboard.

this thread is getting shilled by CTR.
maybe because

$ strings wlinsurance-20130815-A.aes256 | head -c 8
Salted__
$ strings wlinsurance-20130815-B.aes256 | head -c 8
Salted__
$ strings wlinsurance-20130815-C.aes256 | head -c 8
Salted__
$ strings insurance.aes256 | head -c 8
Salted__

I think it's better to ignore them. they have to sage and insult so it's very easy to spot them.
docquery.fec.gov/cgi-bin/forms/C00578997/1046461/sb/ALL

You know that your buzzword is irrelevant now that Trump has won, right? Did you ever know what it meant in the first place?
Not sure why wikileaks used OpenSSL in a pinch for symmetric encryption, though.
Stop talking to yourself, please. Try supporting your arguments next time with facts instead of making insinuations.

CTR existed before you discovered reddit and this place. Link above you shows that they are still in action and paying shills. Election is over but now they want the 33k emails to never get out.

00000000: 5361 6c74 6564 5f5f 2f14 0a2a 6671 09b6 Salted__/..*fq.. [email protected]/* */ -p -d -in last3blocks.aes -out last3dec
salt=2F140A2A667109B6
key=460EBADE3CCC9AD2E6D223EB119435F947CC802044295EA90793AEC981AE3183
iv =20E75E1E60ADF1C345E420EB9CD935BA

salt=2F140A2A667109B6
key=C44D5867FFE37E08397DE9A4CC8058EAED59C20EB66759D7F78C960C2B91A200
iv =5F5A6DFC5CCF0A50AD7502BD047076CE
bad decrypt
140706456762008:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:529:

salt=2F140A2A667109B6
key=C44D5867FFE37E08397DE9A4CC8058EAED59C20EB66759D7F78C960C2B91A200
iv =5F5A6DFC5CCF0A50AD7502BD047076CE
bad decrypt
140211908560536:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:529:

-rw-r--r-- 1 main main 30 Jan 4 02:11 last2dec
-rw-r--r-- 1 main main 16 Jan 4 02:11 last2decwrong
-rw-r--r-- 1 main main 46 Jan 4 02:13 last3dec
-rw-r--r-- 1 main main 32 Jan 4 02:13 last3decwrong

00000000: 820c 4eba 0000 1706 e09c 8e37 0109 d68a ..N........7....

None of your rambling at this point makes any sense. I think anons nailed it on the head that you're a schizo.

What doesn't make sense in his post? I just tried it and the padding bytes are there.

Not the padding bullshit, the retarded "CTR CTR CTR" bullshit.
It's clear that he's just going to keep bumping his own thread with the bullshit from the bitmessage channel, anyways, until bump lock. And he's mentally ill so he'll probably recreate it.

This seems like a real issue. No need to politicize it. Better to just focus on the code itself.

# openssl example

# make a file with openssl using a known hash

$ openssl enc -aes-256-cbc -k secret -p -P -S 3BDF8C61573E236F
salt=3BDF8C61573E236F
key=1BF5078022C5B290545A8DFA210C4CCFD8A7FE337940E1338D1FEE2DDDDD6C24
iv =FDB6855114ACE6690A70AD25444F9B58

# store the salt in binary

$ perl -e 'print pack "H*", "3BDF8C61573E236F"' > salt

# use the first 16 bytes of the key as your md5 hash

$ echo ":1bf5078022c5b290545a8dfa210c4ccf" > temp

# put the hash and salt into a file

$ cat salt temp > opensslhash

# use that information to compute the password

$ ./john -form='dynamic=md5($p.$u)' opensslhash
secret (;ߌaW>#o)

# it finds the password which is 'secret'

No, it's not a real issue. The retards in this thread don't know anything about encryption. If anything, the only problem with any of this is hash iterations.
Other retards have "convinced" you that this is an issue, because you're actually incompetent.
lel
Protip: it doesn't. How fucking stupid are you?

Your post is the equivalent of "UNLOCK THE DOOR WITH THE KEY (AMAZING FIND, BACKDOOR CONFIRMED)"
Why haven't you fucking retards killed yourself yet? You don't understand encryption, you can't read the most basic C imaginable, and yet you're still here on Holla Forums pretending you know anything about technology.

Recovering the password is not needed. Only hints at its value that speed up a brute-force search. And most passwords have shit for entropy, like shills have for brains.

You're chasing a red herring. EVP_DecryptFinal_ex marks an error "bad decrypt" if the last few bytes decrypted do not match a known value. Your "padding oracle" is irrelevant. Study padding oracle attacks until you understand why. I'm tired of explaining this over and over. I'll believe you if you can show how to make an actual attack with your claimed oracle.

I'm not OP. I've been also pointing out that most of what's been posted here are red herrings--the only place a backdoor could be hidden is the RNG. Certain posters seem rather touchy about that bit.

Yes, it did. Because "secret" is in your dictionary and John the Ripper is a dictionary attack tool. This is why you don't use dictionary words as passwords.

Padding oracles are red herrings when we're talking about OpenSSL enc(1) as I have repeatedly explained. Also, I'm not the only one posting in this thread. Tag-teaming shills is fun.

this thread is fucking retarded and the fact that none of the drooling morons screaming about this for the past 4 months have accomplished anything says it all

Which is why the only problem here is iteration count.

$ openssl enc -aes-256-cbc -k 717c0e -p -P -S 3BDF8C61573E236F
$ perl -e 'print pack "H*", "3BDF8C61573E236F"' > salt
$ echo ":99b76c0b6e2fb2e258dafe7bb2119b68" > temp
$ cat salt temp > hashnodict
$ ./john -form='dynamic=md5($p.$u)' --fork=4 --incremental hashnodict
Loaded 1 password hash (dynamic=md5($p.$u) [128/128 AVX 4x3])
Node numbers 1-4 of 4 (fork)
Press 'q' or Ctrl-C to abort, almost any other key for status
2 0g 0:00:00:01 0g/s 1336Kp/s 1336Kc/s 1336KC/s 25cd03..236de1
4 0g 0:00:00:01 0g/s 1264Kp/s 1264Kc/s 1264KC/s tj4847..mato142
3 0g 0:00:00:01 0g/s 959724p/s 959724c/s 959724C/s dunes4..duez1m
1 0g 0:00:00:01 0g/s 1636Kp/s 1636Kc/s 1636KC/s r176013..sammmard
4 0g 0:00:00:52 0g/s 1257Kp/s 1257Kc/s 1257KC/s jeslounn..jesertou
2 0g 0:00:00:52 0g/s 1152Kp/s 1152Kc/s 1152KC/s mmrdoch..mmrdn11
1 0g 0:00:00:52 0g/s 1318Kp/s 1318Kc/s 1318KC/s frufo07..fr37812
3 0g 0:00:00:52 0g/s 1264Kp/s 1264Kc/s 1264KC/s flselan..flsesia
717c0e (;ߌaW>#o)

$ openssl enc -aes-256-cbc -k 717c0e -p -P -S 3BDF8C61573E236F
$ perl -e 'print pack "H*", "3BDF8C61573E236F"' > salt
$ echo ":99b76c0b6e2fb2e258dafe7bb2119b68" > temp
$ cat salt temp > hashnodict
$ ./john -form='dynamic=md5($p.$u)' --fork=4 --incremental hashnodict
Loaded 1 password hash (dynamic=md5($p.$u) [128/128 AVX 4x3])
Node numbers 1-4 of 4 (fork)
Press 'q' or Ctrl-C to abort, almost any other key for status
2 0g 0:00:00:01 0g/s 1336Kp/s 1336Kc/s 1336KC/s 25cd03..236de1
4 0g 0:00:00:01 0g/s 1264Kp/s 1264Kc/s 1264KC/s tj4847..mato142
3 0g 0:00:00:01 0g/s 959724p/s 959724c/s 959724C/s dunes4..duez1m
1 0g 0:00:00:01 0g/s 1636Kp/s 1636Kc/s 1636KC/s r176013..sammmard
4 0g 0:00:00:52 0g/s 1257Kp/s 1257Kc/s 1257KC/s jeslounn..jesertou
2 0g 0:00:00:52 0g/s 1152Kp/s 1152Kc/s 1152KC/s mmrdoch..mmrdn11
1 0g 0:00:00:52 0g/s 1318Kp/s 1318Kc/s 1318KC/s frufo07..fr37812
3 0g 0:00:00:52 0g/s 1264Kp/s 1264Kc/s 1264KC/s flselan..flsesia
717c0e (;ߌaW>#o)

Partially correct. While a low iteration count does weaken the KDF, this weakness is excusable given the KDF's age. The possibility that the salt gives clues about the passphrase is a separate issue.
THE KDF IS A RED HERRING
THE "PADDING ORACLES" ARE RED HERRINGS
EITHER THE RNG IS FISHY OR THERE IS NO FIRE HERE

Partially correct. While a low iteration count does weaken the KDF, this weakness is excusable given the KDF's age. The possibility that the salt gives clues about the passphrase is a separate issue.
THE KDF IS A RED HERRING
THE "PADDING ORACLES" ARE RED HERRINGS
EITHER THE RNG IS FISHY OR THERE IS NO FIRE HERE

Partially correct. While a low iteration count does weaken the KDF, this weakness is excusable given the KDF's age. The possibility that the salt gives clues about the passphrase is a separate issue.
THE KDF IS A RED HERRING
THE "PADDING ORACLES" ARE RED HERRINGS
EITHER THE RNG IS FISHY OR THERE IS NO FIRE HERE

Yes, John the Ripper can do more than simple dictionary attacks. You requested "incremental" mode and the "secret" password was all of 6 characters long.
Put simply, John the Ripper is a brute-force tool. It doesn't do cryptanalytic attacks. If JtR can solve your password in any reasonable amount of time, your password is bad.

password is 717c0e this time.

Yes, John the Ripper can do more than just dictionary attacks. The fact remains that JtR is a password-guessing program. A password consisting of six hex digits has at most 24 bits of entropy, although john was searching a larger space than only hex digits. That the password was still found in less than minute should tell you something:

Short passwords are not secure.

Yes, John the Ripper can do more than just dictionary attacks. The fact remains that JtR is a password-guessing program. A password consisting of six hex digits has at most 24 bits of entropy, although john was searching a larger space than only hex digits. That the password was still found in less than minute should tell you something:

Short passwords are not secure.

How many times does it need to be explained to you that
1) the PRNG is not seeded with the fucking password
2) even if it were, OpenSSL is CSPRNG, and has been tested for bias many times
Thus, it means that even if you do seed the PRNG with a passphrase, it's non-recoverable. Yes, you can seed a PRNG with a high entropy string, even fucking private keys, and it's non-recoverable. It's not bad practice. Your problem at that point is not that you're feeding it the password, it's that you have no single or multiple high quality seeds available to you on your system besides the password.
If you do feed the PRNG a single, high quality seed like a high entropy passphrase, there's nothing doing so if you're on an entropy starved system.

They did it with RSA.

You should really lurk more around here. I'm not saying you will learn much from the constant shitflinging that goes on around here. But people like me might give you good pointers on where to look for computer security.

If you're really new, you might want to start with watching a few days worth of defcon videos.

Then we agree that the passphrase has no business being added to the RNG entropy pool, no? I've repeatedly said that I don't know if the passphrase is ending up in the entropy pool or not and that the claim that the passphrase is used to derive the salt is the only actual allegation in OP. Further, OP claims that the insertion of the passphrase into the entropy pool isn't directly in the code, but is by some indirect process that involves memory-management shenanigans. I have no proof of OP's claims, but we've seen only insults instead of even an attempt to disprove OP's claims.
Great, so hopefully there is no easy way to invert the RNG. Or OpenSSL's CSPRNG may be breakable. Or the CSPRNG may be faster than KDF+decrypt, providing a means for an attacker to filter out most incorrect guesses, even if the attacker cannot directly recover the passphrase from the salt. (Note that a passphrase with more than 64 bits of entropy cannot be recovered even if the RNG is invertible because the salt is only 64 bits.)
Then the correct answer is to fail--not to produce a potentially weak "random" value.

For the sake of argument, assume that the CSPRNG is a random oracle applied to the entropy pool. (If you're trying to lecture anyone on cryptography, you should know what that means.) There is still a problem if the only entropy is the passphrase--two messages encrypted with the same passphrase will then have the same salt. Since OpenSSL derives the key and IV as (key, IV) = KDF(passphrase, salt), this means that those two messages will be encrypted with the same key and the same IV. (This is a problem even if we consider the KDF to be another random oracle.) Reusing the same initialization vector for multiple messages is a known misuse of CBC mode and significantly weakens the system.

still uncertain whether the low-energy shilling is bait or means we're onto something

That's not how it works. You're assuming that the PRNG will always end up at the same state with RAND_bytes when you seed a private key, along with a few other bits of simple sources like nanotime, etc.

Anyways, RAND_poll does in fact seed from urandom, and arc4random, when available.
github.com/openssl/openssl/blob/master/crypto/rand/rand_unix.c#L124-L220

Instead of shitposting paragraphs about how WE MAY BE ONTO SOMETHING, like the retarded anons on the bitmessage channel, you could've found this file yourself in less than 30 seconds. Platform-dependent seeding if not initialized, entropy poll stirring, etc.
github.com/openssl/openssl/blob/master/crypto/rand/md_rand.c#L278

Fuck off. The thread is over. You're as fucking stupid as they are.

Did you read the code you posted?

If you were paid to post here you are about to get fired.

Why do you keep bumping this thread, fucktard?

Oh, wait, I figured it out:
You're just mentally ill. Sad.

/* put in some default random data, we need more than just this */ l = curr_pid; RAND_add(&l, sizeof(l), 0.0); l = getuid(); RAND_add(&l, sizeof(l), 0.0); l = time(NULL); RAND_add(&l, sizeof(l), 0.0);

Please stop spamming this thread with sages and insults. If you think there is nothing there then ignore the thread. Why do you come and post here every day if it's just "mentally ill" people posting?

Mainly because I want this thread to hit bump lock because I'm tired of this retarded as fuck thread on this board.
By the way, fuckhead, I'm not the only user saging and insulting your stupid ass.
As comical as it is that you pretended you have "better things to do" as to why you couldn't find unix_rand and all of those other files, nor the functions, all while shitposting paragraphs about how WE MAY BE ONTO SOMETHING, it's a retarded as fuck thread.
Save your schizophrenic roleplaying for somewhere else, and fuck off. You just dilute this board with horse shit and keep retarded threads like this alive, on top of the already annoying "linux recommendation" and all of the other cancer.
Faggot.

ok now I'm interested

/* * If the PRNG state is not yet unpredictable, then seeing the PRNG * output may help attackers to determine the new state; thus we have * to decrease the entropy estimate. Once we've had enough initial * seeding we don't bother to adjust the entropy count, though, * because we're not ambitious to provide *information-theoretic* * randomness. NOTE: This approach fails if the program forks before * we have enough entropy. Entropy should be collected in a separate * input pool and be transferred to the output pool only when the * entropy limit has been reached. */

if (do_stir_pool) { /* * In the output function only half of 'md' remains secret, so we * better make sure that the required entropy gets 'evenly * distributed' through 'state', our randomness pool. The input * function (rand_add) chains all of 'md', which makes it more * suitable for this purpose. */ int n = STATE_SIZE; /* so that the complete pool gets accessed */ while (n > 0) {#if MD_DIGEST_LENGTH > 20# error "Please adjust DUMMY_SEED."#endif#define DUMMY_SEED "...................." /* at least MD_DIGEST_LENGTH */ /* * Note that the seed does not matter, it's just that * rand_add expects to have something to hash. */ rand_add(DUMMY_SEED, MD_DIGEST_LENGTH, 0.0); n -= MD_DIGEST_LENGTH;

/* * state[st_idx], ..., state[(st_idx + num_ceil - 1) % st_num] are now * ours (but other threads may use them too) */

#ifndef GETPID_IS_MEANINGLESS if (curr_pid) { /* just in the first iteration to save time */ if (!MD_Update(m, (unsigned char *)&curr_pid, sizeof curr_pid)) goto err; curr_pid = 0; }#endif if (curr_time) { /* just in the first iteration to save time */ if (!MD_Update(m, (unsigned char *)&curr_time, sizeof curr_time)) goto err; if (!MD_Update(m, (unsigned char *)&tv, sizeof tv)) goto err; curr_time = 0; if (!rand_hw_seed(m)) goto err; }

/* * rand_hw_seed: get seed data from any available hardware RNG. only * currently supports rdrand. */

int RAND_poll(void){ u_int32_t rnd = 0, i; unsigned char buf[ENTROPY_NEEDED]; for (i = 0; i < sizeof(buf); i++) { if (i % 4 == 0) rnd = arc4random(); buf[i] = rnd; rnd >>= 8; } RAND_add(buf, sizeof(buf), ENTROPY_NEEDED); OPENSSL_cleanse(buf, sizeof(buf)); return 1;}

In the example given, which you were saying is fine, where the passphrase is the only source of entropy, that is how it works.
Great! Can you prove that RAND_poll is reliably called before a salt is generated under all conditions? Can you show that there is no way for a Unix-platform OpenSSL to use a different RAND_poll that doesn't use urandom?
I haven't been repeating that. I've been working this entire thread to systematically eliminate "somethings", and so far have narrowed the scope to the RNG, at which point, instead of help in eliminating that too and restoring confidence in OpenSSL, I get massive pushback from shills spewing insults. Something's fishy here. I don't know if it's the RNG or shillbait, but something's fishy.

(air-five on tag-teaming the shill)
...
The uid and gid will almost certainly be constant for a given user and are probably predictable for single user systems (aka "PCs") if the distro is known to the attacker. That leaves pid, which might be 16 bits, if you're lucky. I wonder what the break-even point is for file length before 2^16 CSPRNG evaluations covering pid to check for a matching salt are faster than KDF+decrypt on each candidate passphrase?

Alright proxy samefaggot, i was assuming you people would have decency but subhumans like you still feel a need to try to save face even after redemption is impossible. This will end in nothing since it's basically trying to get an admission out of a naughty child even though everyone knows the kid is guilty and the kid is aware everyone knows it and they were already punished anyway. But i'll go through anyway just to see how far you get before you shut the fuck up. SERIOUSLY, STOP TALKING ABOUT SUBJECTS THAT YOU KNOW ARE COMPLETELY ALIEN TO YOU. ANYONE, AND I MEAN ANYONE WITH MINIMAL KNOWLEDGE ON THE ANY SUBJECTS YOU HAVE PRETENDED TO KNOW ABOUT WILL BE EASILY BE AWARE OF IT FORM THE FIRST POST. WHAT ARE YOU DOING IS SAYING YOU CAN DRIVE A CAR BUT DON'T KNOW WHAT A STEERING WHEEL IS. The reason i didn't just blow you the fuck out is because any real explanation involves autistic walls of text such as this one that you're probably going to dismiss as "too long didn't read i'm smurt lol". First off the most retarded of all comments but not the first one:

You're basically telling me some random bothered reverse engineering a processor enough to be able to have the knowledge to build a carbon-copy of a piece of it so they can use literally the world's most time consuming, least efficient and hardest way to improve their program's performance by flipping 1s and 0s. You don't know anything about computers so let me make another thing clear for you, programming languages are just a way to make that shit understandable to a human. Those 1s and 0s ultimately represent a simplified version of how electricity acts in the processor. I recommend you look up steve wozniak and how he made an apple computer with color, that was the time when a computer processor's transistors were literally hammered to a wooden board and a game basically involved something bullshit low like a few hundred instructions over a second and one of the key people in the progress of computers had issues with it, in fact he didn't even come up with himself but he instead learned it from looking at someone else's deisgn (although to be able to do that it requires that same knowledge anyway). Now imagine someone knowing what the hell to do when editing machine code of a processor they didn't even create themselves and had to reverse engineer from nothing, a processor that does tens of billions of multiple instructions (modern cpus don't only do a single instruction per clock) per second over multiple separate cores and we haven't even talked cpu memory yet.

It won't ever be the only fucking source of entropy. There's always time, PID, etc. That was the point.
You forgot nanotime, jackass.
You also forgot that it seeds with urandom or arc4random, along with some more sources depending on the platform.
Stop bumping the thread, you imbecile.

aren't both always 0 for root?
seems like attacks are feasible at this point

Also, this is the hilarious bit.
This guy is so fucking stupid, pretending he can read C, that he didn't even bother to ctrl+f RAND_poll in RAND_bytes, which is what generates the salt.

I guess I'm done laughing at this sad soul, it really is pathetic what fucking trash Holla Forums has attracted.

Here's a tip: don't fucking ask people to PROVE to you that it does something. Go ask the question yourself, and if it doesn't, then we can have a discussion on why that's bad.
Not everyone has the temper to fucking spoonfeed your retarded ass. I'm not going to sit here and copy+past the DOCUMENTED CODE where the functions are simple and do exactly what the documentation suggests.

God damn I hate this board.

It seems like you're a mentally defective subhuman who should really stop posting, tbh. If you don't have the fucking attention span to read the thread, or understand what we're talking about, then fuck off.
But who am I kidding, you're probably responding to yourself.

Salt is seeded with uid? That's constant and zero if you're root. The range of possible pids is very small and time can be directly seen if you see when the file was created. This seems like a big deal or am I missing something?

Yeah, you're missing many lines of RAND_poll, but don't let that stop you from shitposting instead of actually reading the file, jackass.
You want to know why this fucking retard didn't post his epic maymay reaction image along with three lines entirely out of context, until I posted the very accessible, documented, and easily findable file?
Because this thread is filled with fucking morons.

I'm not sure why you are calling me a jackass...
That part of the code has not only been posted but even the valgrind logs for it and some observations are in the text files that seem to have started this thread. Here they are in case you haven't read them.
ghostbin.com/paste/xqtea
ghostbin.com/paste/o2xcz

Holla Forums - SSL added and removed here™

Actually not, but you go ahead thinking that.
CTRL+F "often applied" -> only match is your post
WTF are you quoting?

What are file timestamps? (Hint: "time" is known to an attacker) I've already pointed out that PID is unlikely to be more than 16 bits.
Yes, the KDF is a red herring. You can read. I'm so proud of you. Maybe the other autists will also pick that up and concentrate weaponized autism on the RNG.
CTRL+F "RNG MIGHT" -> only match is your post
I've not used those exact words, but I'll take it as close enough. I'll say it again, I've been narrowing the scope of any possible backdoors here, and the RNG is the only one of OP's claims still standing. You're going to help knock it down, no? Or you're just going to spew insults?
And how often does that clock actually tick? I've observed microsecond resolution at best, myself. Also, file timestamps, but nanotime is often omitted when data is transferred, so this is probably limited to a file found on the box that encrypted it. At most, 30 bits of entropy, but more likely to be 20, some or all of which may be known to an attacker.

It's only called if a particular global variable in OpenSSL's data segment is zero. If something sets that variable before the first call to RAND_bytes, it'll never be called. Easy target for a TAO bit-flip. Also, if the RNG somehow gets its pool erased or replaced (malloc shenanigans) after it has first been seeded, RAND_poll will not be called again.
Careful with that blood pressure.

Yes, but there's usually no need to run openssl(1) as root. Might be one additional bit (root/not-root) of entropy, maybe.
Yes, if urandom has not been read to seed the RNG properly or malloc shenanigans have replaced the entropy pool that contains the bytes from urandom. Such an event should be more obvious than what we're seeing, though, unless the replaced pool still contains some entropy. Note that this is the one claim from OP that I can't dismiss out-of-hand.

No, none of those schizophrenic, rambling posts even mentions RAND_poll, which is where the initialization, the SEEDING, of the pool happens.
You're also referring to the rambling posts where the aspie goes on a tirade where he found a new bug called "Heartattack", which consists of nothing but retarded insinuations (implying MD5 is somehow broken in the context it's used for the KDF), totally doesn't understand when the salt is used and isn't, and my personal favorite that you and him both share, the ignorance that led you to read those valgrind logs and not knowing what the fuck is going on.
Above is already explained up thread, btw.

The better question is, why are you bumping this garbage thread? Schizophrenic rambling is not content. The exception is when actually competent individuals like Terry Davis shitpost.

/* * Parallel threads may interfere with this, but always each byte * of the new state is the XOR of some previous value of its and * local_md (intermediate values may be lost). Alway using locking * could hurt performance more than necessary given that * conflicts occur only when the total seeding is longer than the * random state. */ state[st_idx++] ^= local_md[k]; if (st_idx >= STATE_SIZE) st_idx = 0;

The valgrind logs seem to be mostly about malloc tricks. I'm going to try to recreate them. Interesting example I just saw:

void *CRYPTO_malloc(size_t num, const char *file, int line)
{
void *ret = NULL;

allow_customize = 0;

(void)0x7ffff78c4620; (void)46;
ret = malloc(num);

return ret;
}

So not only do you still not know what TAO means, you don't know why such an attack is infeasible?

Chances are that if someone makes almost a dozen totally retarded claims and slaps a label on it called "Heartattack" (nice ego) then it's safe to just ignore it all.

can you give us an example of BULLRUN covertly introducing weaknesses into the encryption standards? show us how it's done. we all want to learn from you.

europarl.europa.eu/document/activities/cont/201410/20141016ATT91322/20141016ATT91322EN.pdf

heart attack was the name snowden gave the vulnerability. not op. read a fucking book.

Because FUCK YOU SHILL, that's why. Perhaps one of Holla Forums's RWDS will find your sorry shill ass some day.

1. "TAO" has become a general term for "NSA fuckery".
2. BULLRUN was specifically to weaken standards, not implementations.
3. "TAO bit-flip" = TAO breaks into a system, tampers with the software and leaves. Or supplies a pre-tampered update via QUANTUMBULLSHIT or whatever-the-NSA-calls-it.

A stopped clock is right twice a day. And dismissing everything a tinfoiler says "because tinfoil" reeks of argumentum ad hominem, just like you reek of pilpul.

THIS
If there's anything here, this'll be involved. A backdoor in the public OpenSSL sources can't be obvious. Speculation: multiple free()s and other shenanigans eventually result in about 3/4 of the RNG entropy pool being set to zero under certain conditions, which may include a small patch to the OpenSSL binary, if this supports a targeted attack.

That bit you've pasted must be derived from an actual call. The address is the address of a string naming the source file that calls CRYPTO_malloc() on line 46. Both of those rvalues are discarded. Their presence is probably to shut up some lint(1) tool that doesn't like the existence of a path through the code that doesn't use every parameter.

Speculation: that's probably from a call around the first attempt to use RDRAND, which crashes valgrind because valgrind doesn't support the RDRAND instruction yet. I explained this in . Ignore the remarks about the initialization vector being a leak in that post. I explained my mistake in .

One other note: when this thread fills up, we'll need to make another one just to piss off that shill. I can't because Torfag.

it looks like some were found recently
github.com/guidovranken/openssl-x509-vulnerabilities

No, it was the name the stupid autist on bitmessage gave it.

No, it has not. It's used by fucking retards.
But that's wrong, you fucking retard.
BULLRUN is a catch-all for attempts to defeat encryption, it's called "the Bullrun Decryption Program" with various ECI labels: APERIODIC, AMBULANT, AUNTIE, PAINTEDEAGLE, PAWLEYS, PITCHFORD, PENDLETON, PICARESQUE, and PIEDMONT and more.
At least I don't reek of some roleplayer who can't even grasp a project structure and begged people to find certain files and/or explain to him what functions are doing. All while pretending he has "better things to do" at the same time he's shitting out paragraphs and bumping this thread.
Fuck off, retard.

Also, see nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html
Again, embarassing thread.

Stop posting in it every day then.

wiki.openssl.org/index.php/Random_fork-safety

```Don't use RAND_bytes```

emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/

#ifndef PURIFY /* purify complains */#if 0 /* The following line uses the supplied buffer as a small * source of entropy: since this buffer is often uninitialised * it may cause programs such as purify or valgrind to * complain. So for those builds it is not used: the removal * of such a small source of entropy has negligible impact on * security. */ MD_Update(&m,buf,j);#endif#endif

... (do some precomputations, like hashing current process ID)#ifndef PURIFY#if 0 /* Don't add uninitialised data. */ (BASTARDIZATION BY Kurt) MD_Update(&m,buf,j); /* purify complains */#endif (BASTARDIZATION BY Kurt)#endif... (create random from a PRNG and put it to buf, return)

... (some precomp)/* * Don't add uninitialised data. MD_Update(&m,buf,j); */... (some postcomp)

wew laddy
You fucking retards are still going to keep bumping up by copy pasting out of context quotes and observations made by others after having been made fun of for your own stupid as fuck observations, and applying a label to it as if it's they're a singular, coherent thing and also pretending that you're some sort of information security wizard with that ego check.

Fuck off, retard. Go back to /g/.

contributing toward bumplock limit

...

because it's already been done to death you fucking idiot
opensslrampage.org/

At this point, I'm convinced that nothing that I've used OpenSSL's enc(1) for is at risk. I've also had enough of your splitting hairs over which exact codename the NSA used for what.

You understand that we'll make another thread when this one fills up just to piss you off, right?

I'd really like a citation for just what construction ssleay_rand_add() implements, and why the input buffer isn't simply hashed in one call "MD_Update(&m, buf, num);".
My hunch is that a backdoor here would be too obvious--aside from the Debian OpenSSL incident, which was either a direct backdoor or the result of a bug in whatever lint(1) the Debian maintainer used.

If you're looking for possible backdoors in OpenSSL's enc(1) command, the RNG is not so much the target as how it is used. There are two run-time behaviors that would be troubling:
1. If malloc shenanigans result in part of the entropy pool being reused for some other buffer that then gets passed to OPENSSL_cleanse(), which would destroy some of the collected entropy.
2. If the passphrase is passed to RAND_add() after the pool has been partially destroyed and before the salt is generated.

Predictable salts are a problem if and only if the salt entropy is low enough for two different messages to be encrypted with the same passphrase and same salt, which would mean that they were encrypted with the same key and IV, exposing the underlying cipher to some cryptanalytic attacks unique to this misuse of CBC mode.

The RNG has been audited--in isolation. The RNG is not used in isolation. The OpenSSL internal malloc is a possible hiding place, but it is likely that this is only a set-up for a targeted attack--the standard OpenSSL sources and binaries built from them are probably not affected.

Another key detail that is highly suspicious: modern glibc (any version from the past decade) aborts the program immediately if a double free() occurs. If OpenSSL is using an internal malloc that bypasses this safeguard, then attention really needs to be focused on the OpenSSL malloc and its use. In fact, I think that this was one of the big things that LibreSSL ripped out.

Yes.

openbsd.org/papers/bsdcan14-libressl/mgp00022.html

To make crypto library from scratch you must create the universe.

FYI: the Heartattack writeup came from this channel on BitMessage

[chan] de995093c3873da70881ddf0bc1bb0f714ff361e653a1030d193497dbaba6355

Shit is going down there, this is where the MD5 compression function was first publicly broken

You mean the retarded autist writeup?
Nothing was broken, and you are a fucking retard.

Did you miss the part where the MD5 compression function was broken?

that's libressl. it's an openssl fork that fixed
issues but did not explain them.

You miss the part after the compression function? Where it's not really broken?
Fuck off back to /g/ please.

OK how about this. If the compression function is not broken what would someone claiming they have broken the compression function be unable to do?

Remember that preimaging the compression function is not the same as a full preimage. Do you understand that difference at least?

The MD5 compression function is literally broken, code has been posted, this is not up for debate, anyone can run it

No, not really fucktard. It's autists circlejerking over hexadecimal tricks.
Might make for an entertaining thread on /prog/ but unfortunately /prog/ died years ago.
Of course, you could demonstrate an actual preimage attack on md5, but you can't, so you won't. You'll just be here shitposting in this thread.
Oh, even more hilarious, the "BM-" ID in that bitmessage channel is back in the channel asking if the "preimage project" is completed, after he'd copy+pasted hexadecimal + magic numbers from the jokester who fooled him in the other channel.
I'm beginning to think that these channels are some sort of epic ruse or attempting to encourage others to join just with the fact that people are saying retarded shit.

Either way, have fun with your hex tricks.

I'd really rather not paint a target on my back by setting up a BitMessage node right now. (It's not about running the node in itself, but starting it up now when I haven't had one before.) Can you relay any important details between here and there?
No surprise there--full MD5 collisions are known, so the existence of free-start collisions (where the compression function produces the same output for two different inputs and two chosen digest states) is obvious. MD4 is hilariously broken--a collision attack is known that requires only 3 operations--verifying the collision is almost as expensive as finding it. Yes, MD4 is still used for hashing Windows passwords.

Back on topic, SHA1 is also a concern at the moment--free-start collisions are known, but the best known attack on the full SHA1 only reduces 2^80 collision resistance to 2^60, and requires an enormous amount of memory. Breaking the compression function doesn't automatically break the full digest. No collision on the full SHA1 has been published. See: en.wikipedia.org/wiki/Hash_function_security_summary

All this matters because the OpenSSL RNG (at least in the older version that I've got close at hand) uses the first digest algorithm compiled into the library from this list: SHA1, MD5, MDC-2DES, MD2. An attack on MD5 may help attacks on the RNG in the special case that the target is using a build of OpenSSL that doesn't include SHA1. You would have to be an idiot to exclude SHA1, but idiots exist and this could be a convenient "oops, how did that happen?" way to insert a backdoor.

Unfortunately, every proof I've got quickly for that is zero-knowledge--it proves it to the person asking, but not to any bystander, since the verifier and prover could collude. Collisions are easier to prove--announce the colliding inputs.

The important things I've got that the BitMessage channel needs to know:
1. The invalid opcode errors from valgrind are a red herring--Valgrind doesn't implement the RDRAND opcode yet, file a bug report mentioning the instruction sequence from the log--"0x48 0xF 0xC7 0xF0 0x72". Once this bug in Valgrind is fixed, analysis should proceed smoothly, but you might find more unsupported opcodes, follow a similar procedure if you do.
1a. If, as I suspect, the OpenSSL RNG is replaced with RDRAND when RDRAND is available, you'll need to patch OpenSSL to remove RDRAND support or to fake that RDRAND always fails.
2. The "VOID" is another red herring--those are references that shut up some lint(1) somewhere and the compiler will discard them. In any case, all they can leak is information about OpenSSL's own source code--information that an attacker already has. 0/10 useless backdoor. (The GNU Coding Standards recommend against inserting casts to void to "pacify a lint checker" in section 5.3, so the use of such useless code to silence lint(1) isn't new.)
3. The KDF is deterministic and must remain consistent--a KDF that isn't what it claims to be would be obvious as soon as someone tried to replicate the generated key using external tools--and the success of such an attempt started this discussion. The KDF is probably a red herring, unless the use of MD5 with the public salt introduces biases into certain key bits.
3a. The output of the KDF is not available to an attacker--inverting MD5 is an interesting academic exercise, but will not help to break files encrypted with OpenSSL's enc(1). (But see item 4a!)
4. The RNG is, by definition, inconsistent--an RNG seeded with only the passphrase and predictable inputs will cause the salt to leak information about the passphrase. Black-box testing can't easily detect this. Only detailed data-flow analysis will trace passphrase->RNG->salt, if such a data flow exists.
4a. The RNG uses a particular message digest algorithm chosen at compile time from a hard-coded list. If higher-priority digests are excluded from the build, the RNG can use MD5. This could enable partial recovery of the RNG state from the salt value if MD5 preimages can be found. Again, this would only affect "special" builds of OpenSSL.
5. The use of an internal malloc is a concern--particularly since glibc will immediately abort the program if a double free() occurs. If OpenSSL bypasses this safeguard with an internal malloc, then the operation and uses of OpenSSL malloc need to be carefully scrutinized.
5a. If the internal malloc can be caused to return a pointer into the RNG entropy pool to a caller that will subsequently pass the buffer to OPENSSL_cleanse(), then holes can be blown in the collected entropy. Depending on when exactly this is done, it may be possible for the RNG initialization to be effectively undone, reducing the entropy of the salt to a small value and the passphrase, if the passphrase is used to seed the RNG.
In summary--if there is a backdoor into OpenSSL's enc(1), it's in some combination of the RNG and OpenSSL's malloc.

Some of the posts can be read here:
beamstat.com/chan/2443399a5a1bd21819a1569af2215753ac5bcab9fb7c3331a5850ede95cbd054
beamstat.com/chan/de995093c3873da70881ddf0bc1bb0f714ff361e653a1030d193497dbaba6355
I think they've had severe spamming problems since the day that someone 'broke the rules' and posted the progress outside the channel (e.g., this thread).
I was able to run their compression function code. if you give me a hash I should be able to give you an text+IHV that produces it.

Produce it: c8d8c0ba8d6ca2c12dc57b205dbd9383

Thanks, I finally figured out how get posts out of that site.

That is output from the MD5 compression function and not from md5sum, right? Noone's claiming to have a preimage attack on full MD5 yet.

From Bitmessage
I can actually use the method to retrieve the password used to encrypt with AES. I just need enough bits of known plaintext in the thing to be decrypted.

For Bitmessage

Given sufficient (theoretically 2 AES blocks) known plaintext, can you recover the 128-bit or 256-bit AES key directly? This would be a very significant break on AES itself if you can. Key recovery is supposed to be the single hardest attack against a block cipher.

More importantly, does OpenSSL's KDF weaken the system? Can you recover a password for OpenSSL enc(1) faster or with less known plaintext than you need to directly recover the AES key and IV? Does a long password take longer to recover than a short password? How much does effect does password length have? It should be exponential, if the SAT solver is internally doing a brute-force search. If a 3-character password is recovered in time T, then a 6-character password should be recovered in time T^2 and a 12-character password in time T^4. If doubling password length doesn't square the time to recover the password.......you've got something big.

This direction (inverting MD5 and breaking AES) is a novel cryptanalytic attack. This is not a backdoor in OpenSSL. If these claims are substantiated, all use of AES is at risk, not just OpenSSL.

It's not novel, it's known. Hence, iteration accounts.
Please stop bumping this thread.

explain the attack

The attack is computing what's basically a rainbow table with the salt.
It's prohibitive in modern KDF.
en.wikipedia.org/wiki/Key_derivation_function#Key_stretching

Nothing novel has been proposed on bitmessage. Like I said, the md5 "preimage" (lel) would make for a good thread on /prog/ years ago, but even that is sleight of hand.

what the hell are you talking about. stop embarrassing yourself. you clearly can't keep up with this thread. stop posting in it. hide it or whatever you have to do. when they finish and it goes public you'll want to pretend you knew from the beginning. right now you are acting exactly like the heartbleed deniers that couldn't see a simple overflow. then someone made the exploit and gmail had to go for hours. that's the type of person you are. someone skeptical of skepticism while pretending to sound smart. it's not working. get a real job.

Listen, you fucking retard, if you want to LARP on your aspie bulletin board, that's fine, but keep it there.
The post I was replying to (inverting MD5 and breaking AES) is nonsencical. What you should be saying is that you're reducing the key space to brute force.

This is not a novel crypto attack. It's just the result of you faggots not knowing what you're talking about.
And if you don't know that the md5 script is a sleight of hand, then your opinion is worth less than dogshit.

Go back to bitmessage, retard. Be sure to post your resident jokester's ramblings on HN or le reddit again, I'm sure it will be good for some laughs to somebody who gets the autistic joke.

it's obvious you don't understand what you are talking about. the 'sleight of hand' can be recreated by anyone.calling people retards probably works for you while you play video games on your shitty windows computer but it won't work here. saging doesn't do anything either. there will be more threads. you're the only one larping here. pretending you care so much about a thread that in your opinion is stupid. it doesn't make sense for someone to post in it every day and try everything they can to hide it.

Go ahead and diff pymd5 and that script, champ. It's not doing what you think it's doing.

Just did the diff.
The only difference is that A, B, C and D are parameters instead of always being [0x67452301L,0xefcdab89L,0x98badcfeL,0x10325476L]. Everything else is identical.

So recreate it on input that matters. Screaming "LOOK MOM I CAN FUCK UP ENCRYPTION AND THEN IT'S EASY TO CRACK" for 300 posts is not an argument.

Those aren't the only differences, and the difference you point out is choosing systematically different magic initialization values paired to each hexadecimal string.
I'm not going to explain the trick, but he's definitely an autist, that's for sure.

All this to say, preimage resistance is worse than originally thought in MD5, with one or two papers, but this 'demonstration' has nothing to do with any of that and is just a sleight of hand. And you retards are still sperging out about a small addon to OpenSSL that desperately needed a loving maintainer since before you underage faggots were born. Hard to be a loving maintainer to OpenSSL though.
So, I'll say again: iteration counts, and the default message digest in any version not older than your mother's cooch is sha256, almost two fucking years ago.

default digest on your copy of openssl is md5 right now.

run this and post the result
$ openssl enc -aes-256-cbc -k password -p -P -S 3BDF8C61573E236F

No, it's not, and again you don't know how to use OpenSSL
github.com/openssl/openssl/blob/master/apps/enc.c#L262-L263
openssl.org/docs/man1.1.0/apps/sha256.html

Also, proof of commit, this was Dec 21, 2015:
github.com/openssl/openssl/commit/f8547f62c212837dbf44fb7e2755e5774a59a57b

Post the output of this
$ openssl enc -aes-256-cbc -k password -p -P -S 3BDF8C61573E236F

There's no need, autist, because I can just post the version. OpenSSL 1.0.2k 26 Jan 2017
In other words, my version of OpenSSL on a rolling has had a default message digest of sha256 for two years.

That's the difference between an attack on the full MD5 and an attack on the MD5 compression function.

MD5 uses the Merkle-Damgaard construction (see en.wikipedia.org/wiki/Merkle–Damgård_construction ) and this means that MD5 consists of repeated applications of a compression function to a hash state (A, B, C, D). The compression function produces a new hash state from the old hash state and a block of the input message. For the first block a "nothing up my sleeve number" is used (see en.wikipedia.org/wiki/Nothing_up_my_sleeve_number ) as an initial hash state. The MD5 digest of a message is the final result from this repeated application of the compression function to a padded version of the input.

Constructing a preimage attack on MD5 from a preimage attack on the MD5 compression function isn't easy. The last block of input contains padding that isn't under the attacker's control. The required hash state must also be achieved, requiring another preimage, which requires another preimage, which requires another preimage, and so on until you get a preimage that uses the defined initial hash state for MD5.

you have to post it because everyone else is doing it and confirming that md5 is still used. if you want to argue here you have to get off your windows computer and run it.

$ openssl enc -aes-256-cbc -k password -p -P -S 3BDF8C61573E236Fsalt=3BDF8C61573E236Fkey=6EC664F83C0BA125FEAEB832AEAA0BAC6A108E70D399B43AC748BAA1CA007385iv =23052D293137FA044194471CE0BB9FD9
You sure are fucking stupid. Maybe you should blame your maintainers.

This is a pseudo-preimage (post below). This is the hard part of making a preimage and can be used to make a full preimage (if it's fast and it seems like it is).
iacr.org/archive/eurocrypt2009/54790136/54790136.pdf

For a given hash value HN and a compression function CF, pseudo-preimage is a
pair of (v, M), v =/= IV such that CF(v, M) = H_{N} . First, we describe the generic
algorithm for the Merkle-Damg˚ard hash functions with n-bit output, which converts
pseudo-preimages to a preimage [10, Fact 9.99]. Assume that there is an
algorithm that finds (H1,(M1, M2, . . . , MN−1)) such that Hi+1 = CF(Hi, Mi)
(i = 1, 2, . . . , N − 1) with the complexity of 2x and H1 looks random.
Prepare a table that includes 2^{n/2−x/2} entries of (H1,(M1, M2, . . . , MN−1)).
Compute 2^{n/2+x/2} CF(H0, M0) for random M0. One of the results will agree with one of
the entries in the table with high probability. The required complexity of the attack
is about 2^{n/2+1+x/2}. Therefore, showing how to find (H1, M1) from a given
hash value within 2x, x < n − 2 is enough for a theoretical preimage attack.

you used the -md flag.

$ openssl enc -aes-256-cbc -k password -p -P -S 3BDF8C61573E236F
salt=3BDF8C61573E236F
key=AB3A2645F0E6EFC31502481A3750CE20757E97434C9598B69B7F86B2380F0853
iv =5ABDA5C294815C4AC15F2510EFB479D3

$ openssl enc -aes-256-cbc -k password -p -P -S 3BDF8C61573E236F -md sha256
salt=3BDF8C61573E236F
key=6EC664F83C0BA125FEAEB832AEAA0BAC6A108E70D399B43AC748BAA1CA007385
iv =23052D293137FA044194471CE0BB9FD9

It's not anything because it's a sleight of hand hexadecimal trick.
You took the word of an autist who spams 'doge' ascii text on bitmessage. Literally. Again, reminds me of /prog/.

why do you care so much about this thread?

No, I did not. Blame your maintainers or your old as fuck version and suck a dick. By the way, doesn't the fact that OpenSSL expose the message digest to configure, and default to EVP_sha256, nullify your entire thread? Oh right, it does.

$ openssl enc -aes-256-cbc -md md5 -k password -p -P -S 3BDF8C61573E236Fsalt=3BDF8C61573E236Fkey=AB3A2645F0E6EFC31502481A3750CE20757E97434C9598B69B7F86B2380F0853iv =5ABDA5C294815C4AC15F2510EFB479D3$ openssl enc -aes-256-cbc -md sha256 -k password -p -P -S 3BDF8C61573E236Fsalt=3BDF8C61573E236Fkey=6EC664F83C0BA125FEAEB832AEAA0BAC6A108E70D399B43AC748BAA1CA007385iv =23052D293137FA044194471CE0BB9FD9$ openssl enc -aes-256-cbc -k password -p -P -S 3BDF8C61573E236Fsalt=3BDF8C61573E236Fkey=6EC664F83C0BA125FEAEB832AEAA0BAC6A108E70D399B43AC748BAA1CA007385iv =23052D293137FA044194471CE0BB9FD9

Because I'm tired of reading autist drivel. I thought this thread would go somewhere but after I looked into it I realized it's just autists being autists.

1.0.2 (the version Tor now uses)
github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/apps/enc.c

if (dgst == NULL) { dgst = EVP_md5(); }

1.0.1
github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/apps/enc.c

if (dgst == NULL) { dgst = EVP_md5(); }

1.0.0
github.com/openssl/openssl/blob/OpenSSL_1_0_0-stable/apps/enc.c

if (dgst == NULL) { dgst = EVP_md5(); }

SSLeay
github.com/openssl/openssl/blob/SSLeay/apps/enc.c

EVP_BytesToKey(cipher,EVP_md5(),NULL, (unsigned char *)str, strlen(str),1,key,iv);

They do that for compatibility, probably, mine defaults to sha256 probably because I'm using unstable.
And, if you're encrypting something you should be able to specify the fucking message digest, not that it really matters. How does it feel that your whole thread is based on a command line flag and then dreaming up some preimage attack on md5 to continue LARPing?
Fuck off.

Hide this thread.

How about you fuck off back to bitmessage instead.

I have never seen posts so furiously opposed in all my years online.

Either there is something here that shills are desperately trying to bury, or the shills are trying to send us down a rabbit hole chasing nothing. I don't know which. The shills might even be trying to send us down a rabbit hole chasing nothing, but will get BTFO when we catch the rabbit after all.

It looks like there's at least a previously-infeasible known plaintext cryptanalytic attack on PBKDF1-MD5+AES-CBC, but no evidence of an actual backdoor yet. I don't know if the attack relies on a weak password. I haven't seen a response from Bitmessage to yet. Was it relayed?

ubuntu.com/usn/usn-3181-1/

Ubuntu Security Notice USN-3181-1
31st January, 2017

openssl vulnerabilities

A security issue affects these releases of Ubuntu and its derivatives:

Ubuntu 16.10
Ubuntu 16.04 LTS
Ubuntu 14.04 LTS
Ubuntu 12.04 LTS
Summary

Several security issues were fixed in OpenSSL.

Software description

openssl - Secure Socket Layer (SSL) cryptographic library and tools
Details

Guido Vranken discovered that OpenSSL used undefined behaviour when
performing pointer arithmetic. A remote attacker could possibly use this
issue to cause OpenSSL to crash, resulting in a denial of service. This
issue only applied to Ubuntu 12.04 LTS and Ubuntu 14.04 LTS as other
releases were fixed in a previous security update. (CVE-2016-2177)

It was discovered that OpenSSL did not properly handle Montgomery
multiplication, resulting in incorrect results leading to transient
failures. This issue only applied to Ubuntu 16.04 LTS, and Ubuntu 16.10.
(CVE-2016-7055)

It was discovered that OpenSSL did not properly use constant-time
operations when performing ECDSA P-256 signing. A remote attacker could
possibly use this issue to perform a timing attack and recover private
ECDSA keys. This issue only applied to Ubuntu 12.04 LTS and Ubuntu 14.04
LTS. (CVE-2016-7056)

Shi Lei discovered that OpenSSL incorrectly handled certain warning alerts.
A remote attacker could possibly use this issue to cause OpenSSL to stop
responding, resulting in a denial of service. (CVE-2016-8610)

Robert Święcki discovered that OpenSSL incorrectly handled certain
truncated packets. A remote attacker could possibly use this issue to cause
OpenSSL to crash, resulting in a denial of service. (CVE-2017-3731)

It was discovered that OpenSSL incorrectly performed the x86_64 Montgomery
squaring procedure. While unlikely, a remote attacker could possibly use
this issue to recover private keys. This issue only applied to Ubuntu 16.04
LTS, and Ubuntu 16.10. (CVE-2017-3732)

Update instructions

The problem can be corrected by updating your system to the following package version:

Ubuntu 16.10:
libssl1.0.0 1.0.2g-1ubuntu9.1
Ubuntu 16.04 LTS:
libssl1.0.0 1.0.2g-1ubuntu4.6
Ubuntu 14.04 LTS:
libssl1.0.0 1.0.1f-1ubuntu2.22
Ubuntu 12.04 LTS:
libssl1.0.0 1.0.1-4ubuntu5.39
To update your system, please follow these instructions: wiki.ubuntu.com/Security/Upgrades.

After a standard system update you need to reboot your computer to make
all the necessary changes.

References

CVE-2016-2177, CVE-2016-7055, CVE-2016-7056, CVE-2016-8610, CVE-2017-3731, CVE-2017-3732

OpenSSL is keeping the classic Unix approach to security.

hack.org/mc/texts/classic-multics.pdf

For those that didn't make the connection, this is where this issue came from:
washingtonpost.com/world/national-security/prosecutors-to-seek-indictment-against-former-nsa-contractor-as-early-as-this-week/2017/02/06/362a22ca-ec83-11e6-9662-6eedf1627882_story.html

...

who cares?

That's actually what he did.

So that guy was the Shadow Brokers?