Please note, this is a STATIC archive of website hashcat.net from October 2020, cach3.com does not collect or store any user information, there is no "phishing" involved.
hashcat Forum
Agilebits 1Password support and Design Flaw? - Printable Version

+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Deprecated; Ancient Versions (https://hashcat.net/forum/forum-46.html)
+--- Forum: Very old oclHashcat-plus Support (https://hashcat.net/forum/forum-23.html)
+--- Thread: Agilebits 1Password support and Design Flaw? (/thread-2238.html)

Pages: 1 2 3 4 5


RE: Agilebits 1Password support and Design Flaw? - atom - 04-18-2013

(04-17-2013, 11:27 PM)gat3way Wrote: atom, you are doing the AES decryption on GPU? I guess you are using the table-based approach (such as what OpenSSL does and not what the AES sample from AMD APP SDK does). Do you store the expanded key in local memory or you are doing that on-the-fly? Asking about that because AES decryption is funny if you are doing the key scheduling on-the-fly, for some time I thought that would be impossible, but it is possible and quite feasible, you can even "pre-cache" some data to save some ALU operations on each round.

hey gat3way, i'm doing an all-precomputed approach so that there is not a single rotate left. this is defenitly different from the amd app sdk example but i dont know anything about the openssl one since i never looked at it.


RE: Agilebits 1Password support and Design Flaw? - gat3way - 04-18-2013

You mean having 4 tables rather than one plus rotates?

In the APP SDK sample, they do it precisely as it is described in the papers.

However, you can combine SubBytes,ShiftRows and MixColumns into a sequence of table lookups (either one 256-element uint table plus a rotate operation, or four separate 256-element lookup tables). This though involves more memory accesses is also faster. OpenSSL for example does that (and I guess most implementations do that too).


RE: Agilebits 1Password support and Design Flaw? - kokolbin - 05-09-2013

Hello, Atom.
I see that you know a lot about *.1password files)
Can you help? Look, I know that any new created password has encrypted with 128-bit random key, and this random key has encrypted cbc-AES on key, which is derived by PBKDF2(Salt,MysterPassword). I want know WHERE is this encrypted 128-bit random key stored in 1password files?
I have some suppose:
This is "encrypted"-field from some *.1password file:
Salted__**************************************......
I think that first 8 bytes after "Salted__" is Salt, then is encrypted 128-bit key, and then is data, which is encrypted with this key.
What can you say about it?


RE: Agilebits 1Password support and Design Flaw? - atom - 05-13-2013

The key -itself- is not part of the encrypted data, but using the correct key gives you the correct padding value in the decrypted aes buffer. It need to match 0x10101010


RE: Agilebits 1Password support and Design Flaw? - kokolbin - 05-13-2013

Thank you for the answer, but i think you didn't understand for what I have asked you. I speak about files *.1password, in which data about new created password is stored. Here https://help.agilebits.com/1Password3/cloud_storage_security.html you can read that "Your data is not directly encrypted with your master password. Instead it is encrypted with a random 128-bit number that was picked when 1Password first created your Agile keychain. That 128-bit number is your true decryption key. This key, in turn, is encrypted using your master password." So, I want to find this 128 bit key and to decrypt data.