Ethnic Vagina Finder
The Great Paper Chaser
lawd a mercy
I ended up adding traditional AES encryption with public and private keys. So that’s a layer on top of what I already invented.
Software Development and Programming Careers (Official Discussion Thread)
- Thread starter Blackking
- Start date
-
- Tags
- careers programming
I ended up adding traditional AES encryption with public and private keys. So that’s a layer on top of what I already invented.
null
...
do you exchange new keys with each mail?
Ethnic Vagina Finder
The Great Paper Chaser
It only looks up the public key of the recipient. I was going to write code that cached public keys so it didn’t check every time, but I haven’t decided.
The private key stays on the users client locally so it’s not on any server.
null
...
AI Overview
Long-lived keys are dangerous because they increase the risk of a successful security breach, provide attackers with long-term access if compromised, and create vulnerabilities due to potential obsolescence, outdated algorithms, or lack of rotation. If a key is compromised, a long-lived one can give an attacker persistent access, whereas a short-lived key limits the window of opportunity for them.
Risks of long-lived keys
- Persistent access:
A long-lived key that is compromised can give an attacker a persistent access method with the same privileges as the original owner, increasing the potential damage.
- Increased compromise window:
The longer a key is active, the more time an attacker has to steal or crack it, either through brute force, a data breach, or other vulnerabilities.
- Outdated security:
Old keys may use cryptographic algorithms that have since been found to be weak or insecure. Newer, more secure algorithms are developed, and long-lived keys prevent the use of these updates.
- Hardcoding risks:
Keys that are hardcoded into an application's source code are difficult to change and may remain in use long after they should have been rotated or revoked, as seen in issues with hardcoded passwords.
- Lack of rotation:
Without a regular rotation policy, keys are not refreshed and remain static. This increases the risk of exposure, especially if the key was compromised in the past and the organization was unaware of it.
- Personnel changes:
Keys may not be properly revoked when an employee leaves, leaving a potential back door open for unauthorized access. Regular rotation and immediate revocation are crucial for security.
Forward secrecy - Wikipedia
Ethnic Vagina Finder
The Great Paper Chaser
AI Overview
Long-lived keys are dangerous because they increase the risk of a successful security breach, provide attackers with long-term access if compromised, and create vulnerabilities due to potential obsolescence, outdated algorithms, or lack of rotation. If a key is compromised, a long-lived one can give an attacker persistent access, whereas a short-lived key limits the window of opportunity for them.
Risks of long-lived keys
- Persistent access:
A long-lived key that is compromised can give an attacker a persistent access method with the same privileges as the original owner, increasing the potential damage.
- Increased compromise window:
The longer a key is active, the more time an attacker has to steal or crack it, either through brute force, a data breach, or other vulnerabilities.
- Outdated security:
Old keys may use cryptographic algorithms that have since been found to be weak or insecure. Newer, more secure algorithms are developed, and long-lived keys prevent the use of these updates.
- Hardcoding risks:
Keys that are hardcoded into an application's source code are difficult to change and may remain in use long after they should have been rotated or revoked, as seen in issues with hardcoded passwords.
- Lack of rotation:
Without a regular rotation policy, keys are not refreshed and remain static. This increases the risk of exposure, especially if the key was compromised in the past and the organization was unaware of it.
- Personnel changes:
Keys may not be properly revoked when an employee leaves, leaving a potential back door open for unauthorized access. Regular rotation and immediate revocation are crucial for security.Forward secrecy - Wikipedia
en.wikipedia.org
So I can just add a function or method that forces key regeneration periodically or on demand.
null
...
if you have control on both sides generate a new key pair each time
diffi-hellmann ephemeral keys
but
you can use certificate pinning to .... maybe even in both directions depending on your arch
Ethnic Vagina Finder
The Great Paper Chaser
if you have control on both sides generate a new key pair each time
diffi-hellmann ephemeral keys
but
you can use certificate pinning to .... maybe even in both directions depending on your arch
I don't think it's really needed. As long as the user protects the private key, that's all that matters. And I currently have it configured to where once you create the password, (which happens on the client), it doesn't get saved/stored. So if you lose it, you're assed out. What I would probably do is add an option to simply change the keys by creating a new pair at random. Public key gets updated on the server and the private key gets updated in the software.
Even if you some how decrypt the package you still have to unlock the second layer.
My goal is to make it so that if the government requests issues subpoenas, the info i would be forced to turn over is useless. I would say i've perfected this system to 90% strength. I'm using firebase to store account info and the public keys for example and I want to either use a comparable service based in Switzerland or Iceland which are not under US jurisdiction, and eventually create my over server infrastructure to where I can control everything.
I'm currently working on adding 2FA compatibility as well. This shyt is ill because I'm learning new shyt everyday. And I then have to incorporate it into what i've already built.
null
...
Secure Da Bag
Veteran
Ethnic Vagina Finder
The Great Paper Chaser
null
...
i don't know. maybe there are some marketing people on here.
