Viewing profile — kelson
kelson
HN member- Joined
- Tue, Apr 14, 2015, 4:04 PM UTC
- HN karma
- 27
- Public activity
- 13 items
- HN profile
- View on Hacker News ↗
About kelson
No profile information was provided.
Recent public activity
-
comment
Comment #15540961
Prior art https://www.shysecurity.com/post/20120401-PingFS
-
comment
Comment #12256040
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, hid…
-
comment
Comment #12255951
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 …
-
comment
Comment #12110656
> "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 O…
-
comment
Comment #11899103
> 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 …
-
comment
Comment #11899041
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 sessionI…
-
comment
Comment #9846865
Prior Implementation: http://shysecurity.com/posts/PingFS
-
comment
Comment #9376637
> 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 …
-
comment
Comment #9376233
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 att…
-
comment
Comment #9375824
> 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 …
-
comment
Comment #9375637
> 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 ext…
-
comment
Comment #9375445
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).…
-
comment
Comment #9375278
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 transform…