kelson

5 ms·

1.
by kelson 9y ago
Prior art https://www.shysecurity.com/post/20120401-PingFS
2.
by kelson 10y ago
The flaw may be assuming everything else can be equal in the real world. Obscuring the algorithm has downstream consequences that may/will reduce overall security. For example, hiding the algorithm from whitehats may prevent/disco
3.
by kelson 10y ago
We measure password and cryptographic key security based on their entropy (keyspace) and speed (key tests / second). Given current attacks (GNFS), a 2048-bit RSA key has ~112 bits of security^1 and would take ~20,000 years to brute for
4.
by kelson 10y ago
> "In return for the hollow credits, ConocoPhillips paid Green Diesel $18 million, according to court documents. Shell got stung for $14.4 million, BP for $13.6 million, Marathon Oil for $12.4 million, Exxon $1.2 million. All these
5.
by kelson 10y ago
> just autoincrement nonce=123 and revoke it any time. Does that revoke all tokens (shared "nonce") or update the token on next authentication? Would this "nonce" be stored in the database? > nobody stores user m
6.
by kelson 10y ago
Salt is random data used to cryptographically sign or encrypt data. It sounds like your JWT consists of a userID and a sessionID (stored in Redis). Why not just store your sessionID in a cryptographically signed HttpOnly cookie? In most u
7.
by kelson 11y ago
Prior Implementation: http://shysecurity.com/posts/PingFS
8.
by kelson 11y ago
> Thus the remote access to the RPi wouldn't pose a risk for using the protocol beside the obvious risks that you always get in such a scenario. That risk didn't exist without the custom cipher construct (KC-system is still ind
9.
by kelson 11y ago
Was CC and KC both performed on the Pi? That introduces side channel attacks. Does CC include implementation flaws enabling remote access? An attacker may use the Pi to enhance attacks against the system executing KC. Does the Pi include an
10.
by kelson 11y ago
> I just wanted to show the common idea of "cryptography is black magic, you should never touch it, you can only do bad things" wrong. Per the other thread, this is overwhelmingly likely to decrease overall security without any
11.
by kelson 11y ago
> Thanks for agreeing that we don't lose security when using my construct. I don't agree. The construct may not degrade security under several caveats. Most implementations are extremely likely to share resources, which will in
12.
by kelson 11y ago
You're right; I misread your construct as KC(CC(P)). Your construct [CC(KC(P))] shouldn't be weaker than KC, unless information or resources are shared by CC and KC (such as keys). Shared information or resources may introduce sid
13.
by kelson 11y ago
This is almost always less secure than KC alone, when KC is a well-known secure cipher. A simple example would be a CC that hex-encodes the plaintext before applying some transformation on the data (before you laugh, this exists in enterpri