Probably more related to RHEL compiling openssl in FIPS mode.
1,188 karma · joined June 7, 2014
Agree. For clarity, the "specific input" in the example would be a bytes[0] value larger than 127.
This behavior is also explained here:
https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+no...
However, as the page you link also mentions, a C extension may also opt to use the "Stable ABI", which does not change across major releases (with some caveats).
As a technology, SGX became interesting the moment Intel added the ability for anybody to launch enclaves (and not only the anointed companies that signed NDAs with Intel) and especially when support for it landed in Linux.
Assuming Intel somehow manages to fix its security problem to a decent level, is SGX as a technology worth learning still?
[0] https://www.intel.com/content/www/us/en/security/confidentia...
Matter (formerly CHIP)? The protocol whose identity layer is allegedly based on a blockchain [0]? I think it needs the cloud, in the same way Moxie describes it.
[0] https://staceyoniot.com/blockchain-101-how-distributed-trust...
Really only 3?
Or did you actually mean "cellular"? Mesh indicates a deployment where not all access points have a backbone connection. Cellular indicates a deployment where all access points have a backbone connection.
The catch is that the other elements need to be able to store the secret, and they need to "pair" to the TPM when the motherboard is assembled. Also, scenarios concerning the legitimate replacement of the CPU need to be addressed. Those are all key management tasks that manufacturers are not good at in general... so here we are with unauthenticated sessions...
The announcement is about its availability on the Azure Marketplace.
This should be turned around. There is no evidence that part for the codebase really need to be ported and for which Rust makes a real difference.
> I'm curious why this has to be done in C/Rust. Performance?
ASN.1 is only used during handshakes and I/O of files (the chunk of rust added covers loading of PKCS#7 files which are typically quite small, and not typically dealt with in massive numbers). I doubt the performance hit would be so high. Also, the package wbond/asn1crypto has shown that doing ASN.1 in pure Python can be quite fast.
> What would be different then compared to now that would reduce breakage to such an extent?
The ability to try the feature out and still have a plan B if it doesn't work out, and the possibility to have a smooth, long, relaxed upgrade plan with good warnings and more time to prepare. But to be honest, while writing all this chain of comments, I really doubt there was a real need to add rust into the mix (other than the political angle I already mentioned).
No, but as seen in the first chunk of rust code added, the amount of logic that needs to be constant-time is a) very, very limited to a few primitives only b) algebraic in nature (put differently, it's not where memory bugs will pop up, so using rust over C doesn't even buy you much).
For instance, ASN.1 parsing doesn't need to done in constant time in the vast majority of cases (and in all cases I am aware of).
> And then when said logic stops being opt-in, why wouldn't the same problem arise?
Some friction will certainly remains, but it will be nothing compared to the current breakage.
So either that's still valid (and not too much of rust will come in to make a real difference security-wise) or they have revisited their position and will re-implement a bunch of openssl logic (in rust apparently though, and not in Python as it would be more logical, and as golang does successfully). And in the latter case, why just not focus on wrapping rustls instead?
In either case, the hand is being forced: it's a small amount, and I don't see how it would have been an excessive burden to maintain such a small logic as an opt in for a period. It makes much more sense to read this as a move to forcefully push rust into the python ecosystem.
I am sure this idea surfaced several times in IRC or possibly in the mailing lists. Certainly, the authors have been toying with handling ASN.1 in rust since 2015 [1], which I guess will be the next logical step.
I do agree that this is mostly a political stance. pyca/cryptography is a wrapper sandwiched between a gigantic runtime written in C (CPython/PyPy) and a gigantic library written in C (openssl).
The addition of Rust as dependency enables the inclusion of just 90 lines of Rust [2] where the only part that really couldn't be implemented in pure Python is a line copied from OpenSSL [3] (i.e. it was already available), and which is purely algebraic, therefore not mitigating any real memory issue at all (the reason to use rust in the first place).
The change in this wrapper (pyca/cryptographic) does not move the needle of security in any significant way, and it is really only meant to send the signal that adding Rust in all other Python packages and especially in the runtime itself will now come at no (political) cost.
[1] https://github.com/alex/rust-asn1
[2] https://github.com/pyca/cryptography/blob/main/src/rust/src/...
[3] https://github.com/openssl/openssl/blob/OpenSSL_1_1_1i/inclu...
NIST P curves don't require any special preparation to their private key.
Curve25519 on the other hand requires a bizarre "clamping" (https://neilmadden.blog/2020/05/28/whats-the-curve25519-clam...), partially because the curve has cofactor 8.
Apart from clamping not being fully and clearly justified in most of the earliest specs and papers (which led to a few broken and/or insecure implementations), it makes the whole narrative of the curve being "safe" quite arguable and leaving a flavor of marketing in the mouth (NIST P curves have cofactor 1 so they are "safer" in that respect).
If true, it is even more disappointing.
[1] https://www.theregister.com/2020/07/14/google_amd_secure_vm/
Only SEV-SNP [2] is supposed to address it, but only on new silicon which doesn't exist yet, and that probably not even Google has.
So why is Google releasing this feature if it is so flawed?
[1] https://arxiv.org/pdf/1908.11680.pdf
[2] https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthen...
Is its source code available (including for any TrustZone component), maybe as part of AOSP?
I am OK with the concept and I can value it also as a protection against advanced malware, but only if it is totally transparent (to me!) what data it collects and relies upon.
Doesn't that make obfuscation kind of pointless? Even if your knock-off app knows everything about the API of the original service, it won't be able to use it because it is not the genuine app or maybe it is but it is not running in a real iOS/Android device.
Or maybe this is only meant to include non-Android certified phones (= China)?
ARM TrustZone is predicated on the Secure World being potentially able to monitor and modify the entire Non-Secure World, because it has control over the MMU (see TZASC, TZMA, TZPC). The reverse is clearly impossible.
SGX instead is defined as a "secure" sandbox, it has basically no privilege even over the process it runs in.
Having said that, researches demonstrated examples of SGX-based malware, which is ultimately rooted in the fact that SGX state is not fully observable (i.e. you can load encrypted code, though you need a lot scaffolding). However, such malware uses a lot of tricks whose side effects can be detected (notwithstanding the fundamental microarchs attacks).
That's not what I hear from reputable reverse engineers, at least for IoT devices.
Even though security by obscurity should be frowned upon, and being understood that hiding code might give a false sense of security, most RE workflows assume availability of firmware, and it is a giant pain to start breaking platforms where the unknown firmware must be manually extracted first, especially the boot loader.
https://medium.com/@tomaspueyo/coronavirus-act-today-or-peop...
> Most email encryption on the Internet is performative, done as a status signal or show of solidarity.
Where is the data supporting this statement?
Where can I read an quantitative analysis on how many emails on the Internet are encrypted, and - out of those - the motivation for having them encrypted, all by percentage? Really, I am willing to pay for it.
Or is the author basing it on personal anectodes, by looking at the few mails in his personal mailbox?
Because at that point also my experience in the corporate world is as good as theirs, and it actually proves the opposite on most points.
Over multiple years, I have seen PGP being used to secure all email exchanges about product security with customers, suppliers, partners, security researchers, and even competitors.
Not a single day passes without a PGP email being sent or received.
As far as I can tell, 100% of the emails contain information for objectively sensitive topics (like security flaws, trade secrets, material under NDA, etc).
Even though emails are exchanged with professionals that are skilled and trained in IT security more than your average Joe, new contacts consistently have PGP keys already and they know how to correctly use PGP.
Any suggestion to use Signal or wormholes won't make you look very good(for good reasons), even though it is clear they are great security products.
Security is good enough: we know that because we do objective risk assessments, where sensationalist articles on the Internet don't play a big role.
I can't recall the last time people replied in the clear - though yes, it happened in the past some times. It also happened that people copy & paste & share paragraphs from sensitive emails though, which is as bad.
The main problem I see is not email encryption per se, but the first key exchange. PGP keyservers are bad and avoided.
The second problem is usability, and it is appalling that nobody is able to tackle this for PGP. It is not really rocket science and certainly people are willing to pay for it.
>> Email is end-to-end unencrypted [1] by default.
>> Serious secure messengers foreclose on this possibility. Secure messengers are encrypted by default
TCP is unencrypted by default too; actually and, you know what, it doesn't even support encryption! You use TLS on top of it (in a hop-by-hop way unfortunately).
Same thing for email. The fact that the underlying message is unsecured, does not mean you need to throw it away.
>> Metadata is as important as content, and email leaks it.
This depends on your threat model. In ours, metadata largely doesn't matter.
>> Secure messaging systems make arrangements for “disappearing messages”.
You do understand that this is a big no-no for corporate right?
You must be able to set retention and escrow policies.
You must use data formats that are very likely to be around or re-implementable in the years to come, not hipster apps that will disappear from circulation next year. We love public standards or industry standards.
Sometimes retention rate is "never delete": that's necessary and it is OK.
Other options also based on RSA such as "rsa-sha2-256/512" are fine and will remain supported. In other words, the security problem is not with RSA per se.
Having said that, I have not checked whether the people you list have RSA keys bound to SHA-1...